"Phillip" == Phillip J Eby email@example.com writes:
Phillip> You just said, "Unhandled, KeyboardInterrupt means..." Phillip> If the program doesn't *want* to handle Phillip> KeyboardInterrupt, then it obviously *isn't* critical, Phillip> because it doesn't care. Conversely, if it *does* handle Phillip> KeyboardInterrupt, then once again, it's not critical by Phillip> your definition.
That's not my definition. By that argument, no condition that can be handled can be critical.
By my definition, the condition only needs to prevent the program from continuing normally when it arises. KeyboardInterrupt is a convention that is used to tell a program that continuing normally is not acceptable behavior, and therefore "critical" by my definition.
Under either definition, we'll still need to do something special with MemoryError, KeyboardInterrupt, et amicae, and they still shouldn't be caught by a generic "except Exception". We agree on that, don't we?
Phillip> Note, by the way, that Python programs can disable a Phillip> KeyboardInterrupt [...]. Ergo, it's a control flow Phillip> exception.
Sure, in some sense---but not in the Python language AFAIK. Which control constructs in the Python language define semantics for continuation after KeyboardInterrupt occurs? Anything that can stop a program but the language doesn't define semantics for continuation is critical and exceptional by my definition.
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> [...]
Phillip> On the contrary, it is control-flow exceptions that bare Phillip> except clauses are most harmful to: StopIteration, Phillip> SystemExit, and... you guessed it... KeyboardInterrupt.
That is a Python semantics issue, but as far as I can see there's unanimity on it. I and (AFAICS) Willem were discussing the connotations of the _names_ at this point, and whether they were suggestive of the semantics we (all!) seem to agree on. I do not find the word "condition" suggestive of the "things 'bare except' should not catch" semantics. I believe enough others will agree with me that the word "condition", even "serious condition", should be avoided.
Phillip> An exception that's being used for control flow is Phillip> precisely the kind of thing you don't want anything but Phillip> an explicit except clause to catch.
Which is exactly the conclusion I reached:
[It] makes me wonder if there's any benefit to having a class [ie, CriticalException] between Raisable and KeyboardInterrupt. ...I don't see a need for a class whose members share only the property that they are not catchable with a bare except....
Now, somebody proposed:
Raisable -+- Exception +- ... +- ControlFlowException -+- StopIteration +- KeyboardInterrupt
As I wrote above, I see no use for that; I think that's what you're saying too, right? AIUI, you want
Raisable -+- Exception +- ... +- StopIteration +- KeyboardInterrupt
so that only the appropriate control construct or an explicit except can catch a control flow exception. At least, you've convinced me that "critical exception" is not a concept that should be implemented in the Python language specification. Rather, (for those who think as I do, if there are others<wink>) "critical exception" would be an intuitive guide to a subclass of exceptions that shouldn't be caught by a bare except (or a handler for any superclass except Raisable, for that matter).
By the same token, "control flow exception" is a pedagogical concept, not something that should be reified in a ControlFlowException class, right?
Phillip> If you think that a KeyboardInterrupt is an error,
I have used the word "error" only in quoting Willem, and that's quite deliberate. I don't think that a condition need be an error to be "critical".