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

[Stephen J. Turnbull]

>>>>> "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", and "CriticalException" is an intermediate
class that has no counterpart in Lisp usage.

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

    Willem> But when CriticalException, despite its name, is not a
    Willem> subclass of Exception, that is a bit strange.

Granted.  It doesn't bother me, but since it bothers both you and
Philip Eby, I concede the point; we should find a better name (or not
bother with such a class, see below).

    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!

Your description of the CL hierarchy makes me wonder if there's any
benefit to having a class between Raisable and KeyboardInterrupt.
Unlike SystemShutdown or PowerFailure, KeyboardInterrupt does imply
presence of a user demanding attention; I suppose that warrants
special treatment.  On the other hand, I don't see a need for a class
whose members share only the property that they are not catchable with
a bare except, leading to

Raisable -+- Exception
          +- KeyboardInterrupt
          +- SystemShutdown
          +- PowerFailure
          +- (etc)

or even

Exception -+- CatchableException
          +- KeyboardInterrupt
          +- SystemShutdown
          +- PowerFailure
          +- (etc)

The latter is my mental model, and would work well with bare excepts.
It also would encourage the programmer to think about whether
an Exception should be catchable or is a special case, but I don't
think that's really helpful except for Python developers, who
presumably would be aware of the issues.

The former would be a compromise to allow "except Exception" to be a
natural idiom, which I prefer to bare excepts on stylistic grounds.
On balance, that's what I advocate.

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