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

[Phillip J. Eby]

At 10:53 AM 8/2/2005 -0400, James Y Knight wrote:
>No... KeyboardInterrupt (just like other asynchronous exceptions)
>really should be treated as a critical error. Doing anything other
>than killing your process off after receiving it is just inviting
>disaster. Because the exception can have occurred absolutely
>anywhere, it is unsuitable for normal use. Aborting a function
>between two arbitrary bytecodes and trying to continue operation is
>simply a recipe for disaster. For example, in threadable.py between
>line 200 "saved_state = self._release_save()" and 201 "try:    #
>restore state no matter what (e.g., KeyboardInterrupt)" would be a
>bad place to hit control-c if you ever need to use that Condition
>again. This kind of problem is pervasive and unavoidable.

In my personal experience with using KeyboardInterrupt I've only ever 
needed to do some minor cleanup of external state, such as removing 
lockfiles, abandoning connections, etc., so I haven't encountered this 
issue before.  I can see, however, why it would be a problem if you were 
trying to keep the program *running* - but I've been assuming that 
KeyboardInterrupt is something that always means "attempt to shutdown 
gracefully".  I suppose considering it a critical error might put it more 
clearly in that category.

I'm not 100% convinced, but you've definitely given me something to think 
about.  On the other hand, any exception can happen "between two arbitrary 
bytecodes", so there are always circumstances that need special attention, 
or require a "with block_signals" statement or something.  I suppose this 
issue may have to come down to BDFL pronouncement.