This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Provide tuple of "special" exceptions
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: loewis, ncoghlan, rhettinger
Priority: normal Keywords: patch

Created on 2004-10-01 05:41 by ncoghlan, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
special_exceptions.diff ncoghlan, 2004-10-01 05:41 Add special_exceptions to builtins and exceptions
special_exceptions_no_builtin.diff ncoghlan, 2004-10-01 05:47 Add special_exceptions to exceptions module only
Messages (7)
msg46986 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2004-10-01 05:41
Add a "special_exceptions" tuple to builtins and
exceptions module which lists the exceptions that users
should be careful to avoid accidentally suppressing.

The current list is SystemExit, MemoryError,
KeyboardInterrupt and StopIteration

A 'no builtin' version of the patch is supplied which
only provides 'exceptions.special_exception', and
leaves builtins alone.
msg46987 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-10-01 05:55
Logged In: YES 

Aren't we looking for the inverse of that tuple, some way to

except non-special exceptions:

msg46988 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2004-10-01 06:56
Logged In: YES 

Yes, we are. At the moment, the best way to spell that is:

except special_exceptions:

I think it would be neat to spell that as:

except not special_exceptions:

but that would be a helluva lot more work, and needs this
tuple anyway :)
msg46989 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-10-02 07:16
Logged In: YES 

I don't like the name of the tuple. "special_exceptions"
does not indicate in what way they are special; the name
should more directly indicate what this is  or why one would
use it.

Also, I'm uncertain about the rationale for picking
precisely these exceptions. I agree that one would normally
not suppress SystemExit, and usually not KeyboardInterrupt.
I'm uncertain about MemoryError, and I can't see why
StopIteration would ever occur in a context where exceptions
are suppressed.
msg46990 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2004-10-02 21:15
Logged In: YES 

Hmm, how about "terminal_exceptions" and only include
SystemExit and KeyboardInterrupt?

MWH gave a decent example on py-dev (x = range(sys.maxint))
as to why MemoryError *shouldn't* be included - there are
too many cases where a particular excessive request will
fail, but subsequent, more sensible, memory requests will
succeed. (x = list(somefile.readlines()) would be another

Looking at StopIteration more closely, I'm inclined to agree
with MvL. I can't see any way to trigger it except by
calling an iterator's .next() method directly or indirectly.
And that generally means one is either in a for loop, or
iterating manually looking for StopIteration explicitly.

(For what it's worth, the original list of 'special'
exceptions was based on my reading of Tim Peter's message to
Py-Dev regarding possible restructuring of the exception
msg46991 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2004-10-11 02:25
Logged In: YES 

Not important enough to try and squeeze into the 2.4 release
cycle - reconsider for 2.5
msg46992 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2005-08-01 12:41
Logged In: YES 

Closing as this will be addressed properly by the exception
heirarchy reorg. The relevant exceptions will be grouped
under a common ancestor (hopefully for 2.5).
Date User Action Args
2022-04-11 14:56:07adminsetgithub: 40968
2004-10-01 05:41:29ncoghlancreate