[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Phillip J. Eby]

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
>to "serious-condition",

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 
it...  KeyboardInterrupt.

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.  ;-)