Abstract

Python, as of version 2.4, has 38 exceptions (including warnings) in the built-in namespace in a rather shallow hierarchy. These classes have come about over the years without a chance to learn from experience. This PEP proposes doing a reorganization of the hierarchy for Python 3.0 when backwards-compatibility is not as much of an issue.

Along with this reorganization, adding a requirement that all objects passed to a raise statement must inherit from a specific superclass is proposed. This is to have guarantees about the basic interface of exceptions and to further enhance the natural hierarchy of exceptions.

Lastly, bare except clauses will be changed to be semantically equivalent to except Exception. Most people currently use bare except clause for this purpose and with the exception hierarchy reorganization becomes a viable default.

Rationale For Wanting Change

Exceptions are a critical part of Python. While exceptions are traditionally used to signal errors in a program, they have also grown to be used for flow control for things such as iterators.

While their importance is great, there is a lack of structure to them. This stems from the fact that any object can be raised as an exception. Because of this you have no guarantee in terms of what kind of object will be raised, destroying any possible hierarchy raised objects might adhere to.

But exceptions do have a hierarchy, showing the severity of the exception. The hierarchy also groups related exceptions together to simplify catching them in except clauses. To allow people to be able to rely on this hierarchy, a common superclass that all raise objects must inherit from is being proposed. It also allows guarantees about the interface to raised objects to be made (see PEP 344 [2]). A discussion about all of this has occurred before on python-dev [4].

As bare except clauses stand now, they catch all exceptions. While this can be handy, it is rather overreaching for the common case. Thanks to having a required superclass, catching all exceptions is as easy as catching just one specific exception. This allows bare except clauses to be used for a more useful purpose. Once again, this has been discussed on python-dev [5].

Finally, slight changes to the exception hierarchy will make it much more reasonable in terms of structure. By minor rearranging exceptions that should not typically be caught can be allowed to propagate to the top of the execution stack, terminating the interpreter as intended.

Philosophy of Reorganization

For the reorganization of the hierarchy, there was a general philosophy followed that developed from discussion of earlier drafts of this PEP [7], [8], [9], [10], [11], [12]. First and foremost was to not break anything that works. This meant that renaming exceptions was out of the question unless the name was deemed severely bad. This also meant no removal of exceptions unless they were viewed as truly misplaced. The introduction of new exceptions were only done in situations where there might be a use for catching a superclass of a category of exceptions. Lastly, existing exceptions would have their inheritance tree changed only if it was felt they were truly misplaced to begin with.

For all new exceptions, the proper suffix had to be chosen. For those that signal an error, "Error" is to be used. If the exception is a warning, then "Warning". "Exception" is to be used when none of the other suffixes are proper to use and no specific suffix is a better fit.

After that it came down to choosing which exceptions should and should not inherit from Exception. This was for the purpose of making bare except clauses more useful.

Lastly, the entire existing hierarchy had to inherit from the new exception meant to act as the required superclass for all exceptions to inherit from.

New Hierarchy

+-- BaseException (new; broader inheritance for subclasses)
    +-- Exception
        +-- GeneratorExit (defined in PEP 342 [1])
        +-- StandardError
            +-- ArithmeticError
                +-- DivideByZeroError
                +-- FloatingPointError
                +-- OverflowError
            +-- AssertionError
            +-- AttributeError
            +-- EnvironmentError
                +-- IOError
                +-- EOFError
                +-- OSError
            +-- ImportError
            +-- LookupError
                +-- IndexError
                +-- KeyError
            +-- MemoryError
            +-- NameError
                +-- UnboundLocalError
            +-- NotImplementedError (stricter inheritance)
            +-- SyntaxError
                +-- IndentationError
                    +-- TabError
            +-- TypeError
            +-- RuntimeError
            +-- UnicodeError
                +-- UnicodeDecodeError
                +-- UnicodeEncodeError
                +-- UnicodeTranslateError
            +-- ValueError
            +-- ReferenceError
        +-- StopIteration
        +-- SystemError
        +-- Warning
            +-- DeprecationWarning
            +-- FutureWarning
            +-- PendingDeprecationWarning
            +-- RuntimeWarning
            +-- SyntaxWarning
            +-- UserWarning
        + -- WindowsError
    +-- KeyboardInterrupt (stricter inheritance)
    +-- SystemExit (stricter inheritance)

Differences Compared to Python 2.4

A more thorough explanation of terms is needed when discussing inheritance changes. Inheritance changes result in either broader or more restrictive inheritance. "Broader" is when a class has an inheritance tree like cls, A and then becomes cls, B, A. "Stricter" is the reverse.

Required Superclass for raise

By requiring all objects passed to a raise statement to inherit from a specific superclass, all exceptions are guaranteed to have certain attributes. If PEP 344 [2] is accepted, the attributes outlined there will be guaranteed to be on all exceptions raised. This should help facilitate debugging by making the querying of information from exceptions much easier.

The proposed hierarchy has BaseException as the required base class.

Bare except Clauses Catch Exception

In most existing Python 2.4 code, bare except clauses are too broad in the exceptions they catch. Typically only exceptions that signal an error are desired to be caught. This means that exceptions that are used to signify that the interpreter should exit should not be caught in the common case.

With KeyboardInterrupt and SystemExit moved to inherit from BaseException instead of Exception, changing bare except clauses to act as except Exception becomes a much more reasonable default. This change also will break very little code since these semantics are what most people want for bare except clauses.

The complete removal of bare except clauses has been argued for. The case has been made that they violate both Only One Way To Do It (OOWTDI) and Explicit Is Better Than Implicit (EIBTI) as listed in the Zen of Python [18]. But Practicality Beats Purity (PBP), also in the Zen of Python, trumps both of these in this case. The BDFL has stated that bare except clauses will work this way [17].

Transition Plan

Because of the complexity and clutter that would be required to add all features planned in this PEP, the transition plan is very simple. In Python 2.5 BaseException is added. In Python 3.0, all remaining features (required superclass, change in inheritance, bare except clauses becoming the same as except Exception) will go into affect. In order to make all of this work in a backwards-compatible way in Python 2.5 would require very deep hacks in the exception machinery which could be error-prone and lead to a slowdown in performance for little benefit.

To help with the transition, the documentation will be changed to reflect several programming guidelines:

• When one wants to catch all exceptions, catch BaseException
• To catch all exceptions that do not represent the termination of the interpreter, catch Exception explicitly
• Explicitly catch KeyboardInterrupt and SystemExit; don't rely on inheritance from Exception to lead to the capture
• Always catch NotImplementedError explicitly instead of relying on the inheritance from RuntimeError

The documentation for the 'exceptions' module [6], tutorial [19], and PEP 290 [3] will all require updating.

Rejected Ideas

Acknowledgements

Thanks to Robert Brewer, Josiah Carlson, Nick Coghlan, Timothy Delaney, Jack Diedrich, Fred L. Drake, Jr., Philip J. Eby, Greg Ewing, James Y. Knight, MA Lemburg, Guido van Rossum, Stephen J. Turnbull, Raymond Hettinger, and everyone else I missed for participating in the discussion.

References

Copyright

This document has been placed in the public domain.