At 10:53 AM 8/2/2005 -0400, James Y Knight wrote: >No... KeyboardInterrupt (just like other asynchronous exceptions) >really should be treated as a critical error. Doing anything other >than killing your process off after receiving it is just inviting >disaster. Because the exception can have occurred absolutely >anywhere, it is unsuitable for normal use. Aborting a function >between two arbitrary bytecodes and trying to continue operation is >simply a recipe for disaster. For example, in threadable.py between >line 200 "saved_state = self._release_save()" and 201 "try: # >restore state no matter what (e.g., KeyboardInterrupt)" would be a >bad place to hit control-c if you ever need to use that Condition >again. This kind of problem is pervasive and unavoidable.
In my personal experience with using KeyboardInterrupt I've only ever needed to do some minor cleanup of external state, such as removing lockfiles, abandoning connections, etc., so I haven't encountered this issue before. I can see, however, why it would be a problem if you were trying to keep the program *running* - but I've been assuming that KeyboardInterrupt is something that always means "attempt to shutdown gracefully". I suppose considering it a critical error might put it more clearly in that category. I'm not 100% convinced, but you've definitely given me something to think about. On the other hand, any exception can happen "between two arbitrary bytecodes", so there are always circumstances that need special attention, or require a "with block_signals" statement or something. I suppose this issue may have to come down to BDFL pronouncement. _______________________________________________ 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
