"Willem" == Willem Broekema firstname.lastname@example.org writes:
Willem> So, in short, Keyboard interrupts in Lisp are a Willem> serious-condition, not an error.
Willem> (And what is labeled CriticalException in this discussion, Willem> has in serious-condition Lisp's counterpart.)
I don't see it that way. Rather, "Raisable" is the closest equivalent to "serious-condition", and "CriticalException" is an intermediate class that has no counterpart in Lisp usage.
>> and if an unhandled signal whose intended interpretation is >> "drop the gun and put your hands on your head!" isn't critical, >> what is?<wink>
Willem> Eh, are you serious? <wink>
Yes. Unhandled, KeyboardInterrupt means that the user has forcibly taken control away from the program without giving it a chance to preserve state, finish responding to (realtime) external conditions, or even activate vacation(1), and the program is entirely at the mercy of the user. Usually, the program then proceeds to die without dignity. If it's a realtime application, killing it is probably the only merciful thing to do.
If you were the program, wouldn't you consider that critical?
Willem> But when CriticalException, despite its name, is not a Willem> subclass of Exception, that is a bit strange.
Granted. It doesn't bother me, but since it bothers both you and Philip Eby, I concede the point; we should find a better name (or not bother with such a class, see below).
Willem> I'd prefer the 'condition' and 'error' terminology, and to Willem> label a keyboard interrupt a condition, not any kind of Willem> exception or error.
Now, that does bother me.<wink> Anything we will not permit a program to ignore with a bare "except: pass" if it so chooses had better be more serious than merely a "condition". Also, to me a "condition" is something that I poll for, it does not interrupt me. To me, a condition (even a serious one) is precisely the kind of thing that I should be able to ignore with a bare except!
Your description of the CL hierarchy makes me wonder if there's any benefit to having a class between Raisable and KeyboardInterrupt. Unlike SystemShutdown or PowerFailure, KeyboardInterrupt does imply presence of a user demanding attention; I suppose that warrants special treatment. On the other hand, I don't see a need for a class whose members share only the property that they are not catchable with a bare except, leading to
Raisable -+- Exception +- KeyboardInterrupt +- SystemShutdown +- PowerFailure +- (etc)
Exception -+- CatchableException +- KeyboardInterrupt +- SystemShutdown +- PowerFailure +- (etc)
The latter is my mental model, and would work well with bare excepts. It also would encourage the programmer to think about whether an Exception should be catchable or is a special case, but I don't think that's really helpful except for Python developers, who presumably would be aware of the issues.
The former would be a compromise to allow "except Exception" to be a natural idiom, which I prefer to bare excepts on stylistic grounds. On balance, that's what I advocate.