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

[Brett Cannon]

On 7/29/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> 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!
> 

No problem.  Had this bouncing around in my head for a while.  I just
needed time to finally type it out.

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

Don't know.  If he doesn't come back I will pick up the attribute part
and roll it into this PEP or a separate PEP.

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

Fine by me.  I would just make sure that it is suggested people
typically catch Exception most of the time and discourage direct
catching of Raisable unless they know what they are doing.

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

Is WindowsError used enough to warrant its existence?

> > 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?

Somewhat.  You could say that an object is just its own namespace. 
But I don't see a strong enough correlation to warrant the merging. 
Or you just saying we should rename AttributeError to NameError?

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

But it doesn't have to stay that way.  This is Python 3.0 we are
talking about, so we can change how both work.

But if you want to keep EnvironmentError that's fine.

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

Shouldn't the former inherit from IOError?

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

How about GenericException?  I just don't think RuntimeError is quite
the right name for this.

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

Well, Robert says there is a use case in CherryPy.

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

Fine by me.

> > Should Bare ``except`` Clauses be Removed?
> 
> Yes, see above.
> 

OK.

-Brett