Lambda the Ultimate

It must be me. I can understand how it might be handy receiving the (caller's local) stack in exceptions for debugging inspection, but in all other cases having 'resumable' exceptions has a couple of drawbacks:

1. It permits a disconnect between calling code (that raises exceptions) and exception handling code. In the article's example, exceptions are inspected by a different method (that acts as a catch-all) and the exception-raising code is potentially resumed from this method. This strikes me as poor design as the exception-raising and exception-handling code should be in the same method, right? You know at compile-time which exceptions are non-fatal (HTTP redirects and Authorisation requests), surely these should be handled at the point they are raised so that the caller can gracefully 'resume' after handling these cases properly, and propogate those that cannot be handled.
2. It violates the principle of fail-fast (cf. Erlang), which may or may not be a matter of personal taste, but I would discourage exception handlers that can tinker with the stack and resume execution at the point of exception--it smacks of patching poor design at runtime. Ouch!

Like I said, it must be me.

PL/I signals had this feature, and Multics made much use of it, apparently. In fact, the way to get what we think of today as "normal" exception semantics was to do a GO TO out of the condition handler (e.g., ON ENDFILE GO TO CALCULATE); if you fall off the end, that returns to what caused the signal.

PL/I also supported nested procedures and interprocedure GO TO; so, the ON statement could be thought of — or even implemented, I think — as just a lambda (uh, I mean, "nested procedure") passed to something like C's signal() (except automatically removed at the end of the scope).

Something to think about, maybe.

(Disclaimer: I haven't actually written any PL/I, just read about it; and the nth-hand copy of PL/I for Programmers that I have appears to be older than me.)

So what you're saying is that you want to be able to bind exception throw behaviour dynamically, rather than lexically. The end result being that a caller can bind handler code into any (uncaught) exception throw, without having any way of knowing the source(s) of the possible exceptions, or their root cause.

How, exactly, is one supposed to document the exceptional behaviour of a library class in that case? What possible security gaurantees could one give, if a calling library can inject arbitrary code on any error condition, and ignore or mask the error as it will? How would you even exhaustively test such a thing, other than by ignoring the horrible stuff that your caller could have done to you and pretending you're in some some language?

The Common Lisp condition system also supports resumable conditions, and the definition of protocols for handling those conditions.