On Thu, 12 Jun 2003, Guido van Rossum wrote: > > > I'm actually a bit wary of such a generalization, because > > > KeyboardInterrupt is currently the only *asynchronous* exception that > > > code needs to worry about. There is plenty of code that gives > > > KeyboardInterrupt special treatment, typically of the form: > > > > > > while MoreWorkToDo: > > > try: > > > ...run a chunk of work which may raise arbitrary exceptions... > > > except KeyboardInterrupt: > > > raise # Don't keep going in this case > > > except: > > > ...report the error and continue... > > > > What about SystemExit? > > It was only an example! > > What should be done with SystemExit depends on what the application is > trying to do. In an interactive Python shell, you probably want to > re-raise it. But in other cases, SystemExit is an error like all > others. (For example, consider a loop that walks a directory tree and > runs testcases found in files named "test.py".) Not to be pedantic, but isn't the range of interpretations of SystemExit exactly analogous to that of KeyboardInterrupt? Also remember that pounding Control-C isn't the only way for a process or thread to get a SIGINT (and thus a KeyboardInterrupt). -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4