4 ms·

I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter. One

I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter. One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a different result, executing a different branch.

kazinator 2y ago
An if-like conditional construct will not, by itself, re-evaluate the condition when an exception occurs, unless it is a special exception-aware construct (a weird macro someone made). The conditional construct would itself have to have an internal restart point around the conditional expression, which intercepts the exception. "Condition" is just a silly name for "exception". It does not mean "restartable exception". It's a terminology that Common Lisp copied from PL/I. At the time Common Lisp was being standardized, it was not a common programming language feature, so the naming didn't matter. In the decades since, the world went to "exception". The word "condition" already has a clear meaning in computing, referring to a logical state ("condition control register", "conditional branch", ...). The "condition variable" synchronization primitive (which has no condition-like state!) is bad enough; we don't need to heap more meanings on those words. Note that processor instruction sets have exceptions, precisely restartable, down to the instruction, without requiring a cooperating restart point. E.g. any code can hit a page fault: the exception handling will fix it up, making a page present at the faulting address, and then restart the instruction that faulted.