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

[Willem Broekema]

On 7/31/05, Brett Cannon <bcannon at gmail.com> wrote:
> On 7/31/05, Willem Broekema <metawilm at gmail.com> wrote:
> > I does not seem right to me to think of KeyboardInterrupt as a means
> > to cause program halting. An interpreter could in principle recover
> > from it and resume execution of the program.
> >
> 
> Same goes for MemoryError as well, but you probably don't want to
> catch that exception either.

Well, an possible scenario is that if allocation of memory fails, then
the interpreter (not the Python program in it) can detect that it is
not caught explicitly and print possible ways of execution, like "try
the allocation again" or "abort the program", letting the user
determine how to proceed. Although in this case immediately retrying
the allocation will fail again, so the user has to have a way to free
some objects in the meantime.

I realize it's major work to add recovery features to the CPython
interpreter, so I don't think CPython will have anything like it soon
and therefore also Python-the-language will not. Instead, my reason
for mentioning this is to get the _concept_ of recoveries across. I
think including (hypothetical, for now) recovery features in a
discussion about exceptions is valuable, because that influences
whether one thinks a label like "critical" for an exception is
appropriate.

I'm working on an implementation of Python in Common Lisp. The CL
condition system offers recovery features, so this implementation
could, too. Instead of the interpreter handling the interrupt in an
application-specific way, as Fred said, the interpreter could handle
the interrupt by leaving the choice to the user.

Concretely, this is how KeyboardInterrupt is handled by a CL
interpreter, and thus also how a Python interpreter could handle it:

(defun foo () (loop for i from 0 do (format t "~A " i)))
(foo)
=> 0 1 2 3 <CTRL-C>
Error: Received signal number 2 (Keyboard interrupt)  [condition type:
INTERRUPT-SIGNAL]
Restart actions (select using :continue):
 0: continue computation
 1: Return to Top Level (an "abort" restart).
 2: Abort entirely from this process.
 
:continue 0
=> 4 5 6 ...

> But it doesn't sound like you are arguing against putting
> KeyboardInterrupt under CriticalException, but just the explanation I
> gave, right?

I hope the above makes the way I'm thinking more clear.  Like Phillip
J. Eby, I think that labeling KeyboardInterrupt a CriticalException
seems wrong; it is not an error and not critical.


- Willem