On Mon, Dec 15, 2008 at 03:06:44PM -0700, Stephen Weeks wrote:
: do {
: die 'some text';
: say 'after the exception';
: CATCH {
: say 'caught the exception';
: ...; # what goes here?
: }
: }
:
: My proposal is to call .resume() on the exception object.
It could just be .thrower.leave, if .thrower can return the ?ROUTINE
of fail() or equivalent. Note that fail() has not been exited yet,
so it can be left via a simple .leave without requiring continuation
support. That's one of the reasons we don't unwind the stack while
we're running exception handlers. Not every VM will provide efficient
continuation support.
That doesn't answer the question of whether resumption *should*
be allowed from a failure that isn't expecting it to continue.
The control flow may well be written such that returning from fail() is
just going to mess things up worse, if the user is not expecting fail()
to return. On the other hand, returning from warn() is expected, and
other such routines might have such expectations as well. And the
Resumable role is just moving the arbitrary decision elsewhere,
I suspect. In the absence of an obvious peg to hang the decision on,
it's going to have to be a process of negotiation between broken code
and exception handlers.
Maybe we just make it easy to leave warnings and other known resumables
with a .resume, and for the dicey cases force the exception handler to
do a caller scan to find the correct fail() to leave if it wants to go
to that trouble. And we presume that if it goes to that much trouble
to handle an exception, it knows somehow that leaving the fail() is
appropropriate. But just as likely it will want to throw a 'last',
'next', or 'redo' exception to some outer loop, or maybe enter some
kind of safe mode, if it's a spacecraft. So I think the exception
handlers have to be trusted to make the final determination of how
to handle exceptions, which seems reasonable. Engineers who write
bad exception handlers will lose control of their work.
Larry
