jmettraux/rufus-scheduler — Issue #25: An exception who's #to_s or #backtrace method itself throws an exception stops the scheduler
Author: samfoo
Created: 2011-10-12 06:25:24+00:00
State: open

But how do you commit such nefarious deeds, you might ask?
-----------------------------------------------------------------------------------

```ruby
require 'rufus/scheduler'
class SnidelyWhiplash < Exception
def to_s
raise "*twirls mustachios*"
end

def backtrace
raise "MWAHAHAHAHAHAAHAHA.... *breath*.... MWAHAHAHAHAH"
end
end

scheduler = Rufus::Scheduler.start_new
scheduler.every("1s", :blocking => true) { raise SnidelyWhiplash, "So eeeeeevil" }
```

What exactly is going on here?
-----------------------------------------

In `lib/rufus/sc/jobs.rb#147` there's a bit of code that rescues exceptions and calls `#handle_exception`.

```ruby
begin

trigger_block

job_thread = nil
to_job.unschedule if to_job

rescue Exception => e
@scheduler.handle_exception(self, e)
```

The default implementation of `#handle_exception` calls `Exception#to_s` and `Exception#backtrace` to print out the details of the error. If either of these methods raise an exception they bubble up all the way to the scheduler and seem to stop subsequent jobs from running (I'm not entirely clear *why* -- I think they actually go all the way up to the thread and the thread stops, but I'm not sure).

Either `#handle_exception` should be made (reasonably) safe from exceptions itself, or the scheduler should be resilient to any perfidious exceptions that manage to find their way up to the top. I'm not sure how to accomplish the second and I wasn't sure if the first was an approach that you would agree with, so instead of a patch I decided to submit a bug.