On 7/31/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 7/31/05, Willem Broekema <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
