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

[Willem Broekema]

On 8/1/05, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Uh, according to your example in Common LISP it is indeed an error,

I think you are referring to the first word of this line:

Error: Received signal number 2 (Keyboard interrupt)  [condition type:
INTERRUPT-SIGNAL]

Well, that refers to the fact that it was raised with (error ...). It
says nothing about the type of a Keyboad interrupt condition. (The
function 'error' vs 'signal' mark the distinction between raising
conditions that must be handled otherwise you'll end up in the
debugger, and conditions that when not handled are silently ignored.)

The CL ANSI standard does not define what kind of condition a Keyboard
interrupt is, so the implementations have to make that decision.

Although this implementation (Allegro CL) has currently defined it as
a subclass of 'error', I'm told it should have been a 
'serious-condition' instead ('error' is a subclass of
'serious-condition', which is a subclass of 'condition'), precisely
because forms like ignore-errors, like a bare except in Python, will
catch it right now when they shouldn't. I assume most of the other
Lisp implementations have already defined it as serious-condition.

So, in short, Keyboard interrupts in Lisp are a serious-condition, not an error.

(And what is labeled CriticalException in this discussion, has in
serious-condition Lisp's counterpart.)

> 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>

Eh, are you serious? <wink>

> I didn't miss your point, but I don't see a good reason to oppose that
> label based on the usual definitions of the words or Common LISP
> usage, either.

Well, I'm not opposed to KeyboardInterrupt being in a class that's not
a subclass of 'Exception', when the latter is the class used in a bare
'except'. But when CriticalException, despite its name, is not a
subclass of Exception, that is a bit strange. I'd prefer the
'condition' and 'error' terminology, and to label a keyboard interrupt
a condition, not any kind of exception or error.

> It seems to me the relevant question is "is it likely that catching
> KeyboardInterrupt with 'except Exception:' will get sane behavior from
> a generic user-defined handler?" 

I agree with you that it should not be caught in a bare 'except' (or
an 'except Exception', when that is equivalent).


- Willem