Flexible Exception Handling (in Smalltalk)

It's way too quiet around here, so maybe you'd want to check this blog entry about ST exception handling. Here's the juicy bit:

In Smalltalk... the stack is an argument held in the exception.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I don't get it

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.


It's really cool to have these primitives so that you can write your own debugger as just another program. I would love to have this in Erlang!

I think it's a great principle to try burning yourself with each of these powerful ideas instead of shying away. They aren't that dangerous!

Croquet video

I remember you had a blast watching the Squeak video. I think you'll find the 10/13/2005 Croquet video a lot of fun too.


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

Dangerous language feature used in the worst possible place

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?

Aren't exception handlers

Aren't exception handlers always bound dynamically not lexically?

I should have been clearer

In languages with non-restartable exception handlers, the location of error handling is bound dynamically, but the handler can only make effects via it's lexical scope. By having the stack as an argument, the handler code has available the dynamic scope of the throw locations.

Common Lisp Too

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