Re: how to set breakpoint at exception throw?

["Scott McPeak" <smcpeak@cs.berkeley.edu>]

> > In the debugger, I'd like to put a breakpoint essentially in the
> > 'raise' function.  The idea is to get control whenever an exception is
> > raised, and be able to take a backtrace.
> > Any ideas on how to do this?
> 
> Reverse execution is your friend: simply run the program under the
> debugger; if an uncaught exception causes the program to terminate,
> back-step (command "back") once, and voila, you're at the point where
> the exception was raised, and you can examine the backtrace.
> 
> If your program traps all exceptions or performs finalization before
> re-raising exceptions, you may have to back-step several times, but
> eventually you'll hit the point where the exception was raised.

I tried this and it took me a while to get it right, in particular
because I was using Printexc.catch to catch it at toplevel, and
several places did catch-and-rethrow.  So I thought I'd summarize:

The key was to run it in the debugger, let it say "uncaught
exception", then "back" once.  This puts you in Printexc.catch's code.  
Now do "previous", which backsteps across fn calls, until the
execution point (denoted by "<|a|>" or "<|b|>") is at the start of the
"with" block.  Then "back" to get to the next throw point, "previous"
again to the top of the block, etc.  You have to use "back" to get
from "with" to "raise" -- if you do "previous" it will go haywire; you
have to use "previous" to step across fn calls in the "with" block
because otherwise it takes forever.

But, I'd like to chime in on the side of advocating more support from
the debugger and/or compiler on getting backtraces.  A start would be
a stand-alone fn to retrieve a backtrace in the code itself, and then
a convention about including backtraces in exception objects.  (And oh
yeah, line/col instead of (or in addition to) char offsets would be
nice.)

-Scott