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.

Logged In: YES 
user_id=80475

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

try:
    myfunc()
except non-special exceptions:
    altfunc()

Logged In: YES 
user_id=1038590

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

try:
   myfunc()
except special_exceptions:
  raise
except:
  dealwithit()

I think it would be neat to spell that as:

try:
  myfunc()
except not special_exceptions:
  dealwithit()

but that would be a helluva lot more work, and needs this
tuple anyway :)

Logged In: YES 
user_id=21627

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.

Logged In: YES 
user_id=1038590

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
example)

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
heirarchy)

Logged In: YES 
user_id=1038590

Not important enough to try and squeeze into the 2.4 release
cycle - reconsider for 2.5

Logged In: YES 
user_id=1038590

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).