On Sun, Dec 06, 2009 at 09:28:43PM -0500, Bob Rogers wrote:
> From: "Patrick R. Michaud" <[email protected]>
> Date: Sun, 6 Dec 2009 00:01:24 -0600
>
> TT #1091 and DEPRECATED.pod claim that label-based exception
> handlers are eligible to be removed in 2.1. I think label-based
> exception handlers are necessary; but I'm willing to be proven wrong.
>
> If a handler "should be" a Sub, then presumably a closure should also be
> allowed. In that case, you could create a closure that contained the
> loop_handler body, calling continuations instead of using "goto". But
> not only is that a much more heavy-weight solution, it doesn't avoid the
> inferior runloop issue, either.
>
> Furthermore, if there is an inferior runloop problem with using a
> Continuation as a handler, then there is also a problem with invoking a
> Continuation from a handler. And if that is so, then handler code can't
> make a nonlocal exit, which seems unacceptable in any case.
Is the inferior runloop problem that
1: the exception fires
2: the exception handler is started in an inferior runloop
3: the exception handler completes by resuming execution
4: *that* execution resumes still within the inferior runloop
5: the inferior runloop completes the program to exit
6: the inferior runloop exits
7: the original runloop continues from the point of the exception
?
in which case, what seems to be needed to allow control exceptions to affect
control flow is
1: that the exception handler (or at least the last part of it) runs in
*the same runloop* as where it is declared
2: (by implication) the exception handler is not allowed to return control to
the point where the exception is thrown
Effectively the style of exception handler that is needed here is much like
C's longjmp() - a non-local goto to the point of declaration of the exception
handler, and then the exception handler can make a goto (local or not) to
continue. Not like Perl 5's $SIG{__DIE__} or $SIG{__WARN__} hooks.
Nicholas Clark
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
