[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Guido van Rossum]

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