>>>>> "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> 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".
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
