Comment by phoe-krk

5 years ago

There seems to be no mention of the Common Lisp condition system, which allows for handling of exceptional situations actually done right. Is this omission purposeful?

See https://news.ycombinator.com/item?id=23843525 for a recent long discussion about my upcoming book on the topic. (Disclosure: this is a shameless plug.)

7 comments

phoe-krk

Reply
chrismorgan  5 years ago

Conditions are certainly technically fascinating. I was introduced to them back when Rust used them for I/O error handling. But Rust ~0.8 dropped conditions, because people found them much more confusing than Result<T, E>-based error handling, and almost no one was actually using any of the power of conditions.

Broadly speaking, conditions can be implemented as a library feature, so you can reintroduce such things in cases where the extra functionality is compelling (though now users won’t be familiar with it, so it’ll be much harder to justify).

Other programming languages have been tending in the direction of implementing generators and async/await, which can be used to more smoothly implement some of the key concepts of conditions. (They’re not the same by any means, but related.)

dannas  5 years ago

I've collected references to error handling but - I have to shamefully admit - have never encountered Common Lisp's condition system.

I'll take the time to read up on it properly, but from a quick glance it seems to me to be in the category of non-local transfer of control with a co-routine flavour.

It looks powerful, but I get the sense that a lot of language designers are on purpose trying to restrict the powers of error handling. So returning sym types or error codes are simpler than throwing exceptions which - again looks to me - to be simpler than allowing transfer of control to be decided at run time as in the condition system.

Again, very interesting. And thank you for making me aware of its existence.

  • phoe-krk  5 years ago

    > with a co-routine flavour.

    Kind-of-but-not-exactly. There are no coroutines whatsoever; the main technical defining point is that the stack is not unwound when the error happens, but it is wound further. Some code is executed that then searches the dynamic environment for matching error handlers, which are executed sequentially; these are then capable of executing arbitrary code provided from earlier in the stack in form of invoking so-called restarts; both handlers and restarts are also capable of performing transfers of control to any point on the stack that was properly annotated as being available for such.

fmakunbound  5 years ago

I thought the same thing. If you're surveying error handling approaches, you've got to include Common Lisp's condition system with it's out of band signals and restarts and so on.