Common Lisp Conditions

That is sounds more appropriate for either terminating the program or resumable exceptions like division by zero. In languages with a try-catch construct (specially C++), the complexity of implementing exceptions has to do with stack unwinding. This is where you don't want to restart in an outer context, but want to guarantee cleanup for the call frames you are abandoning.

Expanding on that: the most impressive feature of CL's condition handling is that it doesn't unwind the stack for you automatically.In languages with "exceptions", when an exception gets thrown, you have a chance to catch it, but at that point the stack has already been unwound and there is no way to resume execution at the point where exception was thrown.In CL, you can let someone else (the caller) make the decision on what to do in case of an exception, providing opt

Forgive my ignorance, but what about this method saves us from having to use continuations to unwind/rewind the stack, as Exceptions do?

IIRC, Common Lisp has an UNWIND-PROTECT operator for that. It works even if exceptions are thrown, and it is the reason Common Lisp (as opposed to Scheme) has no continuations.

I'd recommend taking a look at Common Lisps condition system, which does exceptions right.The most important feature is that catch blocks are executed before the stack is unwond, providing the ability for a handler to signal back to the context where the error occurred how it should be handled.It's sad that no other languages implement this and instead simply decide that exceptions are bad.

Common Lisp has an interesting exception system where errors have a chance to be handled without unwindind the stack. Basically, functions also receive an "error handling" object as an extra argument and they consult when they encounter an exception. The error handling object then edcides wether to continue operation, or to unwind back.

Doesn't adding conditions/restarts require your language to have stackful continuations? Those are quite complicated unless you don't bother to make them safe (like C doesn't bother to with setjmp/longjmp). I would be nervous about them for the same reason I am about exceptions.Also, the restart seems to imply that you should "handle" the error, but I think this is really overemphasized cause what are you actually going to do about it? There's nothing t

This was something I really loved during my time in Common Lisp. This was a gem that I was hoping would make it into Clojure, but I think around version 1.3 they decided to abandon the idea and add a library to "make anything throwable" which totally missed the point in my opinion.Are there any other languages that allow the calling scope to specify how lower-level functions handle errors without unwinding the stack?

I'm struggling to understand how your example is not just something any language with error types can do trivially.Every explanation of conditions and restarts I can find explicitly mentions searching the call stack for a handler and jumping into it, then reserving the capability to return to the function the error originated in.This is explicitly non-local and hidden control flow (ie. the much maligned goto of exceptions).The only advantage I can see asserted of having handlers (e

Errors/exceptions, for one, are implemented using continuations.