Section 10.8. Standard Exceptions

10.8. Standard Exceptions

Table 10.2 lists all of Python's current set of standard exceptions. All exceptions are loaded into the interpreter as built-ins so they are ready before your script starts or by the time you receive the interpreter prompt, if running interactively.

Table 10.2. Python Built-In Exceptions

Exception Name	Description
BaseException[a]	Root class for all exceptions
SystemExit[b]	Request termination of Python interpreter
KeyboardInterrupt[c]	User interrupted execution (usually by typing ^C)
Exception[d]	Root class for regular exceptions
StopIteration[e]	Iteration has no further values
GeneratorExit[a]	Exception sent to generator to tell it to quit
SystemExit[h]	Request termination of Python interpreter
StandardError[g]	Base class for all standard built-in excep tions
ArithmeticError[d]	Base class for all numeric calculation errors
FloatingPointError[d]	Error in floating point calculation
OverflowError	Calculation exceeded maximum limit for numerical type
ZeroDivisionError	Division (or modulus) by zero error (all numeric types)
AssertionError[d]	Failure of assert statement
AttributeError	No such object attribute
EOFError	End-of-file marker reached without input from built-in
EnvironmentError[d]	Base class for operating system environment errors
IOError	Failure of input/output operation
OSError[d]	Operating system error
WindowsError[h]	MS Windows system call failure
ImportError	Failure to import module or object
KeyboardInterrupt[f]	User interrupted execution (usually by typing ^C)
LookupError[d]	Base class for invalid data lookup errors
IndexError	No such index in sequence
KeyError	No such key in mapping
MemoryError	Out-of-memory error (non-fatal to Python interpreter)
NameError	Undeclared/uninitialized object (non-attribute)
UnboundLocalError[h]	Access of an uninitialized local variable
ReferenceError[e]	Weak reference tried to access a garbage- collected object
RuntimeError	Generic default error during execution
NotImplementedError[d]	Unimplemented method
SyntaxError	Error in Python syntax
IndentationError[g]	Improper indentation
TabError[g]	Improper mixture of TABs and spaces
SystemError	Generic interpreter system error
TypeError	Invalid operation for type
ValueError	Invalid argument given
UnicodeError[h]	Unicode-related error
UnicodeDecodeError[i]	Unicode error during decoding
UnicodeEncodeError[i]	Unicode error during encoding
UnicodeTranslateError[f]	Unicode error during translation
Warning[j]	Root class for all warnings
DeprecationWarning[j]	Warning about deprecated features
FutureWarning[i]	Warning about constructs that will change semantically in the future
OverflowWarning[k]	Old warning for auto-long upgrade
PendingDeprecationWarning[i]	Warning about features that will be dep recated in the future
RuntimeWarning[j]	Warning about dubious runtime behavior
SyntaxWarning[j]	Warning about dubious syntax
UserWarning[j]	Warning generated by user code

^[a] New in Python 2.5.

^[b] Prior to Python 2.5, SystemExit subclassed Exception.

^[c] Prior to Python 2.5, KeyboardInterrupt subclassed StandardError.

^[d] New in Python 1.5, the release when class-based exceptions replaced strings.

^[e] New in Python 2.2.

^[h] New in Python 1.6.

^[g] New in Python 2.0.

^[f] New in Python 1.6.

^[i] New in Python 2.3.

^[j] New in Python 2.1.

^[k] New in Python 2.2 but removed in Python 2.4.

All standard/built-in exceptions are derived from the root class BaseException. There are currently three immediate subclasses of BaseException: SystemExit, KeyboardInterrupt, and Exception. All other built-in exceptions are subclasses of Exceptions. Every level of indentation of an exception listed in Table 10.2 indicates one level of exception class derivation.

As of Python 2.5, all exceptions are new-style classes and are ultimately subclassed from BaseException. At this release, SystemExit and KeyboardInterrupt were taken out of the hierarchy for Exception and moved up to being under BaseException. This is to allow statements like except Exception to catch all errors and not program exit conditions.

From Python 1.5 through Python 2.4.x, exceptions were classic classes, and prior to that, they were strings. String-based exceptions are no longer acceptable constructs and are officially deprecated beginning with 2.5, where you will not be able to raise string exceptions. In 2.6, you cannot catch them.

There is also a requirement that all new exceptions be ultimately subclassed from BaseException so that all exceptions will have a common interface. This will transition will begin with Python 2.7 and continue through the remainder of the 2.x releases.