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

Brett Cannon bcannon at gmail.com
Sun Jul 31 18:21:45 CEST 2005


On 7/31/05, Willem Broekema <metawilm at gmail.com> wrote:
> On 7/31/05, Brett Cannon <bcannon at gmail.com> wrote:
> > While we do tend to use KeyboardInterrupt as a way to kill a
> > program, is that really control flow, or a critical exception
> > that the program needs to stop because an serious event
> > occurred?
> 
> 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.

> The behaviour of the current Python interpreters is that upon
> encountering an uncaught KeyboardInterrupt (as with any uncaught
> exception), computation is aborted and a backtrace printed. But that
> is not how it /must be/ as there might be alternative interpreters
> that upon encountering an uncaught KeyboardInterrupt will pause
> execution of the program, but then allow the user to either continue
> or abort execution, effectively not stopping but pausing the program.
> 
> Because of this possible recovery, thinking of KeyboardInterrupt as
> "in order to abort the program, the user has caused a keyboard
> interrupt" is wrong; it should be more like just "the user has
> interrupted the computation" and whether or not the program is
> consequently aborted is not predefined.
> 

But interpreter termination is not guaranteed for any exception, even
SystemError since it can be caught and not re-raised.  Plus the common
use of hittting ctrl-c while an app is running is to kill it, not to
pause the execution.

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

-Brett


More information about the Python-Dev mailing list