[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
bcannon at gmail.com
Thu Aug 4 01:40:36 CEST 2005
On 8/3/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> [Guido van Rossum]
> > > OK, I'm changing my mind again about the names again.
> > >
> > > Exception as the root and StandardError can stay; the only new
> > > proposal would then be to make bare 'except:' call StandardError.
> [James Y Knight]
> > I don't see how that can work. Any solution that is expected to
> > result in a usable hierarchy this century must preserve "Exception"
> > as the object that user exceptions should derive from (and therefore
> > that users should generally catch, as well). There is way too much
> > momentum behind that to change it.
> This is actually a good point, and what I was thinking when I first
> responded to Brett.
> Sorry for the waivering -- being at OSCON always is a serious attack
> on my system.
As long as you don't change your mind again on bare 'except's I won't
feel like strangling you. =)
> I'm still searching for a solution that lets us call everything in the
> hierarchy "exception" and *yet* has Exception at the mid-point in that
> hierarchy where Brett has StandardException. The problem with Raisable
> is that it doesn't contain the word exception; perhaps we can call it
> BaseException? We've got a few more things called base-such-and-such,
> e.g. basestring (not that I like that one all that much).
BaseException is what comes to mind initially. You also mention
RootException below. PureException seems too cutesy.
SuperclassException might work. SuperException doesn't sound right.
Co-worker suggested UhOh, but I don't think that will work either. =)
> BTW I just noticed UserException -- shouldn't this be UserError?
Yep, and I already changed it in my personal copy.
> Also... We should have a guideline for when to use "...Exception" and
> when to use "...Error". Maybe we can use ...Exception for the first
> two levels of the hierarchy, ...Error for errors, and other endings
> for things that aren't errors (like SystemExit)? Then the top of the
> tree would look like this:
That makes the most sense. Error for actual errors, exception when
another suffix (e.g., Exit, Iteration) does not fit.
> BaseException (or RootException?)
> +-- CriticalException
> +-- ControlFlowException
> +-- Exception
> +-- (all regular exceptions start here)
> +-- Warning
> All common errors and warnings derive from Exception; bare 'except:'
> would be the same as 'except Exception:'. (I like that particularly
> because I've been writing that in lots of code already. :-)
> A refinement might be to introduce something called Error, which would
> change the last part of the avove hierarchy as follows:
> (first three lines same as above)
> +-- Exception
> +-- Error
> +-- (all regular ...Error exceptions start here)
> +-- Warning
> +-- (all warnings start here)
> This has a nice symmetry between Error and Warning.
> Downside is that this "breaks" all user code that currently tries to
> be correct by declaring exceptions as deriving from Exception, which
> is pretty common; they would have to derive from Error to be
> politically correct.
> I don't immediately see what's best -- maybe Exception and Error
> should be two names for the same object??? But that's ugly too as a
> long-term solution.
I say introduce Error (or StandardError or BaseError) and just live
with the fact that older code will not necessarily follow the proper
naming scheme. We can provide a script that will change source
directly for any class that inherits from Exception to some other
class, namely Error.
More information about the Python-Dev