4 ms·

> Condition handling seems generally useful. There are definitely cases I could have used this. It's probably pretty straightforward to add to languages that ha

by awj 16y ago

> Condition handling seems generally useful. There are definitely cases I could have used this. It's probably pretty straightforward to add to languages that have exceptions. Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone. The exception mechanism has to travel up the call stack to find the handler, and can't get back to where it was. You can fake it in many languages, but you can't retroactively make the language support the behavior. You end up with a nasty mess that, although it may be powerful, is so far removed from the normal idioms of the language everyone you work with will want to kill you for doing it.

kenjackson 16y ago
Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone. 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.
- awj 16y ago
  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.
  - kenjackson 16y ago
    OK, gotcha. I misunderstood. With that I agree.

by awj 16y ago

kenjackson 16y ago

Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone. 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.

awj 16y ago
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.
- kenjackson 16y ago
  OK, gotcha. I misunderstood. With that I agree.