> the exception handler can run before the stack is unwound.
Old basic had an error handling model that is exceptionally elegant in some cases: "on error goto ...", with an an indication (errline, I think?) of where the exception happened, and then you could "resume next" to continue (perhaps after fixing the error condition, if the error handler is somewhere else) or directly restart at an earlier point if that makes sense.
It's simple, a little goto-ish, and has abuse potential - but if actually used, tended to end with robust code where the "usual path" was the simplified "that's what we usually do", and all the "in case something was unexpected" are listed independently. C code using goto for error handling (e.g. in the linux kernel) has similar properties.
try/catch, in all languages it exists, does not let you restart in the middle unless all the error handling code is in-line (which is comparatively disgusting IMO); lisp conditions do, and more - but they only exist in Lisp.
I wouldn't call it robust. It was way too easy to do it wrong by forgetting some statement that could fail, and then your RESUME ended up resuming something you didn't anticipate, with a potentially invalid program state.
Not really, though it does share the property that it executes user code before unwinding the stack (the exception filters), and that the user code can choose to mark the exception as handled and allow the program to continue without unwinding the stack.
However, there is no Restart system, allowing the code that raises an exception to also declare how it can be handled. And there are no alternative exception handling strategies than searching the stack and unwinding in case a suitable handler is not found. Unwinding is not a property of Conditions in general CL, it is just one of the strategies that can be used when signalling a condition.
But in Window's SEH, you can fix up a page fault and re-start the offending instruction. You have access to the detailed machine state, like all the registers and the bad address where an invalid access took place and such.
Old basic had an error handling model that is exceptionally elegant in some cases: "on error goto ...", with an an indication (errline, I think?) of where the exception happened, and then you could "resume next" to continue (perhaps after fixing the error condition, if the error handler is somewhere else) or directly restart at an earlier point if that makes sense.
It's simple, a little goto-ish, and has abuse potential - but if actually used, tended to end with robust code where the "usual path" was the simplified "that's what we usually do", and all the "in case something was unexpected" are listed independently. C code using goto for error handling (e.g. in the linux kernel) has similar properties.
try/catch, in all languages it exists, does not let you restart in the middle unless all the error handling code is in-line (which is comparatively disgusting IMO); lisp conditions do, and more - but they only exist in Lisp.