resumable exceptions and LEAVE/KEEP/UNDO blocks
Daniel Hulme
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.
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.
--
<Customer> Waiter, waiter! There's a fly in my soup!
<Waiter> That's not a bug, it's a feature.
http://surreal.istic.org/ The Answer of the Oracle Is Always Death.
Larry Wall
: 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
Daniel Hulme
> 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.
Yes, I did. I was grepping specifically for the bit on resumable
exceptions and the quoted bit is 80 lines up so I missed it completely.
Thanks for pointing me at it.
[...]
> 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.
OK, that makes sense.
The reason that came up was because on Friday I had a good idea for a
language feature that would have made a task I had been doing that day
much easier. When I checked the spec, though, I found out it was already
in. This is happening increasingly often, which should be reassuring to
all concerned.
--
"Listen to your users, but ignore what they say." - Nathaniel Borenstein
http://surreal.istic.org/ Calm down, it's only ones and zeroes.