[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

Brett Cannon bcannon at gmail.com
Wed Aug 3 19:28:32 CEST 2005

On 8/3/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Phillip J. Eby wrote:
> > +1.  The main things that need fixing, IMO, are the need for critical and
> > control flow exceptions to be distinguished from "normal" errors.  The rest
> > is mostly too abstract for me to care about in 2.x.
> I guess, before we figure out "where would we like to go?", we really need to
> know "what's wrong with where we are right now?"
> Like you, the only real problem I have with the current hierarchy is that
> "except Exception:" is just as bad as a bare except in terms of catching
> exceptions it shouldn't (like SystemExit). I find everything else about the
> hierarchy is pretty workable (mainly because it *is* fairly flat - if I want
> to catch a couple of different exception types, which is fairly rare, I can
> just list them).

Does no one else feel some of the names could be improved upon?  While
we might all have gotten used to them I still don't believe newbies
necessarily grasp what they are all for based on their names.

Then again, if this PEP is viewed more as handling macro issues with
the currnt hierarchy and name changes can be done when we get closer
to Python 3.0 I am happy to drop renaming until we are closer to
actual implementation with a section just listing suggested name
changes and stating that they are just being considered possibl
renaming which will not be finalized until we are closer to Python 3.0

> I like James's suggestion that instead of trying to switch people to using
> something other than "except Exception:", we just aim to adjust the hierarchy
> so that "except Exception" becomes the right thing to do. Changing the
> inheritance structure a bit is far easier than trying to shift several years
> of accumulated user experience. . .
> Anyway, with the hierarchy below, "except Exception:" still overreaches, but
> can be corrected by preceding it with "except (ControlFlow, CriticalError):
> raise".
> "except Exception:" stops overreaching once the links from Exception to
> StopIteration and SystemExit, and the links from StandardError to
> KeyboardInterrupt, SystemError and MemoryError are removed (probably difficult
> to do before Py3k but not impossible).
> This hierarchy also means that inheriting application and library errors from
> Exception can continue to be recommended practice. Adapting the language to
> fit the users rather than the other way around seems to be a pretty good call
> on this point. . .

Well, then StandardError becomes kind of stupid.  The only use it
would serve is a superclass for all non-critical, non-control-flow
built-in exceptions.  I really don't know how often that is going to
be needed.

I do realize it keeps inheritance working for existing code, though. 
I guess that would just have to be a trade-off for

OK, I am convinced; I will revert back to Raisable/Exception instead
of Exception/StandardError.


More information about the Python-Dev mailing list