[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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
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
depending on what they want.
Do we really need these? Let's not add things that won't be used.
> 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,
> Originally meant as an exception for when an event outside of the
> interpreter needed to raise an exception, its use has been deemed
> 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).
> 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.
> 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