Um, yeah.

I'm not at all surprised to hear that the debugger acts a bit funny around
exceptions.  Step and send are (I believe) running through simulations of
code execution most of the time, rather than sending actual messages via
the vm; that means that the debugger has to manage a 'virtual vm' and keep
its code path in sync with where the actual vm would have gone.  Because
exceptions cause code execution to move about the call stack in (to the
debugger) unexpected ways, the debugger can get pretty confused in a hurry
the moment an exception is handled (although an unhandled exception should
leave a more or less normal stack, I think).

As for the fear that Halt can get 'eaten' by handlers set up to handle
other exceptions ... humm.  Halt moved around in the class hierarchy a few
times, eventually winding up as an Error subclass.  In retrospect, perhaps
either a direct Exception subclass, or part of an Interrupt hierarchy which
subclasses from Exception (or possibly Notification), would be a better
place for it to live.

The exception code in the current Squeak release is a framework; filling
out the core Exception class hierarchy and integrating its into the base
classes, and making the debugger exception-aware, are two tasks that would
need done before it would really be properly integrated.  None of that work
is particularly trivial, unfortunately ... .

Paul McDonough,
writing far worse than I should, and speaking off-the-cuff and
not-at-all-officially rather than for my employer (The Fourth Estate)