Previous Page
Next Page

6.4. Exception Objects

Exceptions are instances of subclasses of the built-in, legacy-style Exception class.[*] An instance of any subclass of Exception has an attribute args, the tuple of arguments used to create the instance. args holds error-specific information, usable for diagnostic or recovery purposes. In Python 2.5, class Exception is new-style, since it inherits from the new built-in new-style class BaseException; this, in turn, makes all built-in exception classes new-style in Python 2.5. For detailed explanations of how the standard exception hierarchy changes in 2.5, and how things will move further in 3.0, see

[*] For backward compatibility, Python also lets you use strings, or instances of any legacy class, as exception objects, but such usage risks future incompatibility and gives no benefits.

6.4.1. The Hierarchy of Standard Exceptions

All exceptions that Python itself raises are instances of subclasses of Exception. The inheritance structure of exception classes is important, as it determines which except clauses handle which exceptions. In Python 2.5, however, classes KeyboardInterrupt and SystemExit inherit directly from the new class BaseException and are not subclasses of Exception: the new arrangement makes it more likely that a general handler clause coded as except Exception: does what's intended, since you rarely want to catch KeyboardInterrupt and SystemExit (exception handlers are covered in "try/except" on page 122).

In Python 2.3 and 2.4, the SystemExit, StopIteration, and Warning classes inherit directly from Exception. Instances of SystemExit are normally raised by the exit function in module sys (covered in exit on page 169). StopIteration is used in the iteration protocol, covered in "Iterators" on page 65. Warning is covered in "The warnings Module" on page 471. Other standard exceptions derive from StandardError, a direct subclass of Exception. In Python 2.5, class GeneratorExit, covered in "Generator enhancements" on page 126, also inherits directly from Exception, while the rest of the standard exception hierarchy is like the one in 2.3 and 2.4, covered in the following.

Three subclasses of StandardError, like StandardError itself and Exception, are never instantiated directly (at least, not by Python itself). Their purpose is to make it easier for you to specify except clauses that handle a broad range of related errors. These three abstract subclasses of StandardError are:


The base class for exceptions due to arithmetic errors (i.e., OverflowError, ZeroDivisionError, FloatingPointError)


The base class for exceptions that a container raises when it receives an invalid key or index (i.e., IndexError, KeyError)


The base class for exceptions due to external causes (i.e., IOError, OSError, WindowsError)

          AssertionError, AttributeError, ImportError,
          KeyboardInterrupt, MemoryError,
          NotImplementedError, SystemError, TypeError,
          UnicodeError, ValueError
                FloatingPointError, OverflowError, ZeroDivisionError
                IndexError, KeyError

6.4.2. Standard Exception Classes

Common runtime errors raise exceptions of the following classes:


An assert statement failed.


An attribute reference or assignment failed.


A floating-point operation failed. Derived from ArithmeticError.


An I/O operation failed (e.g., the disk was full, a file was not found, or needed permissions were missing). Derived from EnvironmentError.


An import statement (covered in "The import Statement" on page 140) cannot find the module to import or cannot find a name specifically requested from the module.


The parser encountered a syntax error due to incorrect indentation. Derived from SyntaxError.


An integer used to index a sequence is out of range (using a noninteger as a sequence index raises TypeError). Derived from LookupError.


A key used to index a mapping is not in the mapping. Derived from LookupError.


The user pressed the interrupt key (Ctrl-C, Ctrl-Break, or Delete, depending on the platform).


An operation ran out of memory.


A variable was referenced, but its name was not bound.


Raised by abstract base classes to indicate that a concrete subclass must override a method.


Raised by functions in module os (covered in "The os Module" on page 240 and "Running Other Programs with the os Module" on page 354) to indicate platform-dependent errors. Derived from EnvironmentError.


The result of an operation on an integer is too large to fit into an integer (operator << did not raise this exception; rather, it dropped excess bits). Derived from ArithmeticError. Dates back to Python 2.1; in today's Python versions, too-large integer results implicitly become long integers, without raising exceptions. This standard exception remained a built-in for backward compatibility (to support existing code that raises or tries to catch it). Do not use in any new code.


The parser encountered a syntax error.


An internal error within Python itself or some extension module. You should report this to the authors and maintainers of Python, or of the extension in question, with all possible details to allow them to reproduce the problem.


An operation or function was applied to an object of an inappropriate type.


A reference was made to a local variable, but no value is currently bound to that local variable. Derived from NameError.


An error occurred while converting Unicode to a string or vice versa.


An operation or function was applied to an object that has a correct type but an inappropriate value, and nothing more specific (e.g., KeyError) applies.


Raised by functions in module os (covered in "The os Module" on page 240 and "Running Other Programs with the os Module" on page 354) to indicate Windows-specific errors. Derived from OsError.


A divisor (the righthand operand of a /, //, or % operator, or the second argument to built-in function divmod) is 0. Derived from ArithmeticError.

Previous Page
Next Page