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.
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
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.