[ruby-core:28730] Re: When a trace hook raises an exception, should it terminate the program?

On Wed, Mar 17, 2010 at 5:42 AM, Rocky Bernstein <[e-mail]> wrote:
> In Ruby 1.8 and the Ruby 1.9 trunk when running a trace hook that raises an
> exception not caught by the hook, the program terminates -- whether or not
> there is a rescue further up the call stack, i.e. in the non-hook body.
>
> Ruby 1.9 also gives a stack trace, while Ruby 1.8 doesn't.

This is a pretty peculiar situation. What *should* happen? With the
hook set, if it starts raising exceptions, you start getting errors
happening not in particular methods but in the "inbetween" space
between method calls and lines and pretty much everything. In your
example, even if it rescues, it would hit a c-call event (for the
puts) and raise again before printing anything out.

Perhaps the specification could say that a ruby-land set_trace_func is
wrapped with an implicit rescue and disabled if an error is raised? Or
something?

> How do JRuby, IronRuby and Rubinius and other Rubies handle this? And what
> do the specifications say?

JRuby also terminates. Note that the trace output is slightly
different, since we have different call sequences for some things:

~/projects/jruby ➔ jruby --debug hook_thing.rb
line  :8 (the first event that fires after the hook is set)
c-call === :8 (this is the rescue calling ===)
c-call backtrace :1 (this is the toplevel of JRuby trying to get the backtrace)
c-call first :1 (fallback code because backtrace errored too?)
Exception in thread "main" c-call first :1 (finally, we give up)

There's so many calls and line events happening here, it's pretty much
impossible for anything good to come out of it. Catastrophic failure.

As for other Rubies...I don't know if IronRuby supports
set_trace_func, but Rubinius and MacRuby do not.

> If it is the case that raising an exception in a trace hook unconditionally
> terminates the hooked program, programmers that want to write a trace hook
> that plays nice with programs it hooks against should wrap the hook in a
> begin/rescue block. Or make sure your code never raises an uncaught
> exception.

That seems wise.

- Charlie