Is there a convention for handling exceptions within BackgrounDRb workers?
For example, I have a worker which does some asynchronous data processing
(*not* a scheduled worker) based on some things in the database. However,
if an exception is raised within that worker, then the process for that
worker is killed off. Ideally I would want that worker to just silently
fail and be optimistic that it was an edge case that won''t happen every
time
the worker is invoked.
As of now, I''ve just added some basic exception handling to log the
error
for future inspection like so:
class EmailWorker < BackgrounDRb::MetaWorker
set_worker_name :email_worker
def run(data = nil)
do_stuff
rescue Exception => ex
logger.info ex
end
end
Is this generally the practice for doing exception handling within workers
or is there another approach?
Regards,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080604/14054adf/attachment-0001.html>
On Thu, Jun 5, 2008 at 3:27 AM, Aaron Pfeifer <aaron.pfeifer at gmail.com> wrote:> Is there a convention for handling exceptions within BackgrounDRb workers? > For example, I have a worker which does some asynchronous data processing > (*not* a scheduled worker) based on some things in the database. However, > if an exception is raised within that worker, then the process for that > worker is killed off. Ideally I would want that worker to just silently > fail and be optimistic that it was an edge case that won''t happen every time > the worker is invoked. > > As of now, I''ve just added some basic exception handling to log the error > for future inspection like so: > > class EmailWorker < BackgrounDRb::MetaWorker > set_worker_name :email_worker > > def run(data = nil) > do_stuff > rescue Exception => ex > logger.info ex > end > end > > Is this generally the practice for doing exception handling within workers > or is there another approach? >Currently, there is no other way, but I think, it would be a good idea to have a callback ( on_exception :do_this) and continue with things.
Thanks for the feedback... glad to know we''ve gone down the right path! :) On Fri, Jun 6, 2008 at 5:00 AM, hemant <gethemant at gmail.com> wrote:> On Thu, Jun 5, 2008 at 3:27 AM, Aaron Pfeifer <aaron.pfeifer at gmail.com> > wrote: > > Is there a convention for handling exceptions within BackgrounDRb > workers? > > For example, I have a worker which does some asynchronous data processing > > (*not* a scheduled worker) based on some things in the database. > However, > > if an exception is raised within that worker, then the process for that > > worker is killed off. Ideally I would want that worker to just silently > > fail and be optimistic that it was an edge case that won''t happen every > time > > the worker is invoked. > > > > As of now, I''ve just added some basic exception handling to log the error > > for future inspection like so: > > > > class EmailWorker < BackgrounDRb::MetaWorker > > set_worker_name :email_worker > > > > def run(data = nil) > > do_stuff > > rescue Exception => ex > > logger.info ex > > end > > end > > > > Is this generally the practice for doing exception handling within > workers > > or is there another approach? > > > > Currently, there is no other way, but I think, it would be a good idea > to have a callback ( on_exception :do_this) and continue with things. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080606/abf5da97/attachment.html>