Q about TT #1091 (deprecate label-based exception handlers)

[Patrick R. Michaud]

On Mon, Dec 07, 2009 at 11:29:54AM -0500, Andrew Whitworth wrote:
> > In particular, I think that if we simply provide an opcode or method
> > that an ExceptionHandler (or Continuation?) can use to explicitly
> > request the longjmp back into the original runloop, then we solve
> > the largest part of the current issue.  In other words, we establish a
> > convention -- enforcement to come later -- that well-behaved
> > ExceptionHandlers either return control to the thrower or
> > explicitly signal (via opcode or method) that they are resuming
> > execution in the original context/runloop.
> 
> Herein lies a slightly different problem. Once we leave the inner
> runloop and unwind the C stack, we cannot return. 

That's fine.   An exception handler that is going to resume
control to the thrower wouldn't execute the "return to original
runloop opcode" -- i.e., it would stay in the inferior runloop (as
it should).

> In this case we stay in the inner runloop to execute the handler and
> then when an "exception handler end" op is executed we can make
> informed decisions about where to go.

I agree but I probably wouldn't limit the opcode to the semantic notion 
of "exception handler end".  An exception handler that knows it won't 
resume to the thrower could invoke the "resume execution in the original 
context/runloop" opcode first, and then perform the remainder of any 
exception handling tasks in the original runloop before 
merging control back into its idea of "mainline execution".

Pm