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

[Brett Cannon]

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> M.-A. Lemburg wrote:
> > The reason for my -1 on the renaming and reordering is
> > that it would completely break compatibility of Python 2.x
> > applications with Python 3. Furthermore, there would be next to
> > no chance of writing new applications that run in Python 3
> > and 2, so you have breakage in both directions.
> >
> > Whether this is desired or not is a different discussion,
> > I just want to point out some important things to consider:
> >
> > When moving from Python 2.x to 3.0, renaming could be solved
> > with the help of some scripts, grep et al. However, there
> > would have to be a good reason for each of these renamings,
> > otherwise this only introduces additional porting overhead.
> > Aliases might be a way to provide soft introduction.
> >
> > Something that scripts will not be able to help with are
> > changes in the inheritance tree, e.g. if an application
> > catches a ValueError, the programmer might also expect
> > UnicodeErrors to get caught, if the application catches
> > a TypeError, this may not be aware that the TypeError could
> > actually be an AttributeError.
> 
> I think the problems with this can be minimised by avoiding making changes we
> don't need to. I think only a few changes are needed to get a significantly
> cleaner structure.
> 
> Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:
> 

Nick, are you going go start subbing in for Tim when he is busy and
take my work that I spent hours on, come up with an alternative that
took 10 minutes, and have everyone end up loving your newfangled idea
10x more than my original?  =)

> New Hierarchy
> =============
> 
> Raisable (formerly Exception)
> +-- CriticalException (new)
>      +-- KeyboardInterrupt
>      +-- MemoryError
>      +-- SystemError
> +-- ControlFlowException (new)

As I have said I am fine with moving ControlFlowException out to here,
but it depends if others agree.

>      +-- GeneratorExit
>      +-- StopIteration
>      +-- SystemExit

Good point with SystemExit!  I am definitely +1 on changing that inheritance.

> +-- Exception (formerly StandardError)
>      +-- AssertionError
>      +-- AttributeError

I am still up for moving AttributeError, but with the amount of
arguing going on between where it should go I am not going to be
shocked if we go with the status quo.

>      +-- ImportError
>      +-- TypeError
>      +-- WeakReferenceError (formerly ReferenceError)
>      +-- ArithmeticError
>          +-- FloatingPointError
>          +-- DivideByZeroError
>          +-- OverflowError
>      +-- EnvironmentError
>          +-- OSError
>              +-- WindowsError (possibly remove this from builtins)

If we are going to lack exceptions for other OSs, I say remove it.  No
reason Windows should get special treatment with a built-in exception.

>          +-- IOError
>              +-- EOFError
>      +-- LookupError
>          +-- IndexError
>          +-- KeyError
>      +-- NameError
>          +-- UnboundLocalError

What about UnboundGlobalError?

>      +-- RuntimeError

I still don't like the name.

>          +-- NotImplementedError

Interesting idea, but I don't view them as the same.  Everyone uses
RuntimeError as a Poor Man's Exception, not as an actual runtime
error.

>      +-- SyntaxError
>          +-- IndentationError
>              +-- TabError
>      +-- ValueError
>          +-- UnicodeError
>              +-- UnicodeDecodeError
>              +-- UnicodeEncodeError
>              +-- UnicodeTranslateError
> +-- Warning
>      +-- DeprecationWarning
>      +-- FutureWarning
>      +-- PendingDeprecationWarning

Don't like the idea of having DeprecationWarning inherit from
PendingDeprecationWarning?

-Brett