[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Phillip J. Eby
pje at telecommunity.com
Tue Aug 2 06:31:42 CEST 2005
At 12:25 PM 8/2/2005 +0900, Stephen J. Turnbull wrote:
> >>>>> "Willem" == Willem Broekema <metawilm at gmail.com> 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
I don't think that Lisp's idea of an exception hierarchy has much bearing here.
> >> 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?
You just said, "Unhandled, KeyboardInterrupt means..." If the program
doesn't *want* to handle KeyboardInterrupt, then it obviously *isn't*
critical, because it doesn't care. Conversely, if it *does* handle
KeyboardInterrupt, then once again, it's not critical by your definition.
So, clearly, KeyboardInterrupt is thus *not* critical, and doesn't belong
in the CriticalException hierarchy.
Note, by the way, that Python programs can disable a KeyboardInterrupt from
ever occurring in the first place, whereas none of the other
CriticalException classes can be "disabled" because they're actually
*error* conditions, while KeyboardInterrupt is just an asynchronous
notification - for control flow purposes. Ergo, it's a control flow
exception. (Similarly, a Python program can avoid raising any of the other
control flow errors; they are by and large optional features.)
> 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!
On the contrary, it is control-flow exceptions that bare except clauses are
most harmful to: StopIteration, SystemExit, and... you guessed
An exception that's being used for control flow is precisely the kind of
thing you don't want anything but an explicit except clause to
catch. Whether critical errors should also pass bare except clauses is a
distinct issue, one which KeyboardInterrupt really doesn't enter into.
If you think that a KeyboardInterrupt is an error, then it's an indication
that Python's documentation and the current exception class hierarchy has
failed to educate you sufficiently, and that we *really* need to add a
class like ControlFlowException into the hierarchy to help make sure that
other people don't end up sharing your misunderstanding. ;-)
More information about the Python-Dev