The point I was making was more about the prospect of adding condition handling as a language user to an existing language. Basically that most language implementations make it impossible to add something like this using the tools provided by the language. I suppose at points go it was a bit of a silly one.
The difficulty in adding it to the language when modifying the language implementation is an open option is much lower.
Re:Three unique features of Lisp in 2010
by kenjackson on Saturday January 29, 2011 @12:14AM
(#2154711)
OK, gotcha. I misunderstood. With that I agree.
This depends on how you model control flow. What's become more common now is to have very explicit control flow modeling so you have pseudo-edges from every place an exception can occur to the catch block (of course fewer with synchronous exceptions).
So when the exception is thrown you keep the frame on the stack, shove your IP, and go to the new handler -- like a function call. From the handler you have five potential exit points:
1) Pop stack, jmp... continue control flow from where the exception took place,if recovery succeeds.
2) Fall out the bottom if it was handled, but not "recovered".
3) Go to next recovery handler in list, if there is one.
4) Unwind.
5) New exception.
With that said, there are as many ways to implement exception handling as there EH mechanisms. Every one of mine I've done pretty differently, but in everyone of them I think could implement condition handling pretty easily.