On Mon, Mar 05, 2007 at 01:06:46PM +0000, Daniel Hulme wrote:
: What happens if a resumable exception is propagated through a block with
: a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point.
: It strikes me that what we want it to do is not execute them when the
: exception is propagated, because we don't know whether it's going to be
: resumed or not. If the exception is resumed by its handler, then that's
: fine, as we can call the blocks at the usual time (when the blocks they
: are attached to exit). If the exception is caught and handled and not
: resumed, that would leave us with having to find all the LEAVE &c.
: blocks and call them in the right order when the exception handler
: exits.
:
: In either case, it looks like you have a problem. LEAVE &c. blocks will
: often be used for things like database transactions, where we want to
: ensure that some lock obtained on entering the block is released
: promptly regardless of how the control flow jumps about. In such a
: context, throwing a resumable exception that skips the LEAVE block,
: farts about doing some potentially long computation in a higher-up
: scope, and only calls the LEAVE block to release the lock at some later
: date, seems to be far from the best choice. Sure, we can warn
: programmers to make their resumable-exception handlers short, or to only
: throw non-resumable exceptions from blocks that are likely to be called
: in such circumstances. I suppose that would be an acceptable resolution,
: but it has an aura of non--re-entrant signal handlers about it, so it
: seems like the sort of thing I would like to avoid if anyone is clever
: enough to think of something else to do.
I don't see a problem here. I think you maybe missed the bit that says:
A C<CATCH> block sees the lexical scope in which it was defined, but
its caller is the dynamic location that threw the exception. That is,
the stack is not unwound until some exception handler chooses to
unwind it by "handling" the exception in question.
Exiting blocks are not run until the decision is made to unwind the stack,
which is *after* the exception handlers are run. So all the exception
trampoline has to do to resume is just return; the resume continuation
doesn't really have to be a real continuation in this case.
: BTW, if one is handling a resumable exception, how does one resume it? I
: couldn't find anything explaining how. Having a .resume method (or some
: cutesier name) on the Resumable role would seem to make sense.
To resume a resumable exception the correct thing to do is very
likely nothing. The outermost warning handler is what generally
resumes otherwise uncaught resumables. If you catch a warning,
it defaults to resuming when handled unless you rethrow it as fatal.
Larry
