[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0 (original) (raw)

Guido van Rossum gvanrossum at gmail.com
Sat Jul 30 04:41:37 CEST 2005

On 7/29/05, Brett Cannon <bcannon at gmail.com> wrote:

Well, it has been discussed at multiple times in the past and I have promised to write this PEP several times, so I finally found enough time to write a PEP on reorganizing exceptions for Python 3.0 .

Thanks for getting this ball rolling!

(I wonder what happened to Ping's PEP 344 -- he just dropped out, it seems.)

Below is some feedback.

Often people use a bare except when what they really wanted were non-critical exceptions to be caught while more system-specific ones, such as MemoryError, to pass through and to halt the interpreter. With a hierarchy reorganization, bare except clauses can be changed to only catch exceptions that subclass a non-critical exception superclass, allowing more critical exceptions to propagate to the top of the execution stack as was most likely intended.

I appreciate the attempt to make bare except: less dangerous by not catching certain exceptions, but I worry that these changes might actually make bare except: more likely to be used, which is contrary to the intention. Maybe we should just get rid of it, and encourage people to write

except Exception:

or

except Raisable:

depending on what they want.

MacError UnixError

Do we really need these? Let's not add things that won't be used.

NamespaceException

To provide a common superclass for exceptions dealing with namespace issues, this exception is introduced. Both UnboundLocalError and UnboundGlobalError (the new name for NameError) inherit from this class.

OTOH there's something to say to unify NameError and AttributeError, isn't there?

EnvironmentError

Originally meant as an exception for when an event outside of the interpreter needed to raise an exception, its use has been deemed unneeded. While both IOError and OSError inherited this class, the distinction between OS and I/O is significant enough to not warrant having a common subclass that one might base an except clause on.

-1000. Depending on whether you use open() or os.open() you'll get one or the other for pretty much the same thing.

Also, I think that socket.error and select.error should inherit from EnvironmentError (or maybe even from OSError).

RuntimeError

Meant to be used when an existing exception does not fit, its usefulness is consider meager in Python 2.4 [exceptionsmodule]. Also, with the CriticalException/Exception dichotomy, Exception or CriticalException can be raised directly for the same use.

-0.5. I use it all the time as the "application" exception in apps (scripts) that are too small to define their own exception hierarchy.

StopIteration and GeneratorExit

Inherit from ControlFlowException. Collecting all control flow-related exceptions under a common superclass continues with the theme of maintaining a hierarchy.

Yes, but how useful it this? I don't expect to ever come across a situation where I'd want to catch both, so this is more for organization of the docs than for anything else.

IMO a good principle for determining the ideal exception hierarchy is whether there's a use case for catching the common base class.

IOError

No longer subclasses EnvironmentError.

-1000, see above.

Change the Name of Raisable?

It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1].

Then we'll make it a word. Is Java's equivalent, Throwable, any more a word? In this case I like the parallel with Java.

Should Bare except Clauses be Removed?

Yes, see above.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list