[Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions

[SourceForge.net]

Patches item #1038256, was opened at 2004-10-01 15:41
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470

Category: Core (C code)
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Provide tuple of "special" exceptions

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-11 12:25

Message:
Logged In: YES 
user_id=1038590

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

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-03 07:15

Message:
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)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-02 17:16

Message:
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.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-01 16:56

Message:
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 :)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-01 15:55

Message:
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()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470