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>