I've been having fun with Vorlath's notions of language design, but I haven't picked apart a specific example. Well, here goes - in his latest post, he calls exception handling broken, and explains by way of an example:

I suppose a simple example would not hurt. Take for example opening a file. Currently, we usually check the error code or trap an exception. If the exception isn't caught then it backtracks along the execution chain. Now consider if the open file command passed the error automatically to its parent super cluster along with the filename and other associated information. The super cluster can now pass this information to the GUI sub cluster to display an error message and some kind of option like choosing an alternate file for example. Then the super cluster can replace the filename and retry the open file command. The key here is that there is a centralized location for resource management and handling of subcomponents. So you can have standard recovery practices for the same types of errors. It should also be noted that you can fine tune the error recovery. If you wanted the leaf object itself to try and correct this error, you can do that too. Sometimes, the fact that the file doesn't exist is perfectly OK. But if you run out of memory or hard drive space for example, it can be automatically recover by notifying the user without putting this directly into the main flow of your source code.

I think he's got the handling mechanism of Java/C# in mind here. In those systems, when you get to the handler, the stack has been unwound, so you're stuck wherever you are. Not so in Smalltalk - you can restart the execution chain pretty much anywhere along the chain you want, and you have full context information. I use that in BottomFeeder to deal with problems as they arise in grabbing a feed - the handling is quite different depending on whether the problem arose in the HTTP part of the equation, the XML parsing part of the equation, or the decomposition of XML (RSS/Atom) into domain objects part of it.

In fact, I managed the parsing issues by subclassing (cue the scary music) the XML Parser and tossing in my own, more fault tolerant one. Bottom line - the kind of exception handling he wants already exists - but since it's in Smalltalk, it's "old" technology, and he'll have to go ahead and recreate it from scratch. Just like GC, I suppose.

Another thing - about that centralized error recovery thing - Smalltalk has had a default handler (which you can replace with your own) forever. Unless I'm greatly mistaken, the newest Java SDK from Sun includes that kind of functionality as well (without actually having access to the whole stack, but still).