Exception classes can now be new-style classes, not just classic classes, and the built-in Exception class and all the standard built-in exceptions (NameError, ValueError, etc.) are now new-style classes.
The inheritance hierarchy for exceptions has been rearranged a bit. In 2.5, the inheritance relationships are:
BaseException # New in Python 2.5 |- KeyboardInterrupt |- SystemExit |- Exception |- (all other current built-in exceptions)
This rearrangement was done because people often want to catch all
exceptions that indicate program errors. KeyboardInterrupt and
SystemExit aren't errors, though, and usually represent an explicit
action such as the user hitting Control-C or code calling
sys.exit(). A bare
except: will catch all exceptions,
so you commonly need to list KeyboardInterrupt and
SystemExit in order to re-raise them. The usual pattern is:
try: ... except (KeyboardInterrupt, SystemExit): raise except: # Log error... # Continue running program...
In Python 2.5, you can now write
except Exception to achieve
the same result, catching all the exceptions that usually indicate errors
but leaving KeyboardInterrupt and
SystemExit alone. As in previous versions,
except: still catches all exceptions.
The goal for Python 3.0 is to require any class raised as an exception
to derive from BaseException or some descendant of
BaseException, and future releases in the
Python 2.x series may begin to enforce this constraint. Therefore, I
suggest you begin making all your exception classes derive from
Exception now. It's been suggested that the bare
except: form should be removed in Python 3.0, but Guido van Rossum
hasn't decided whether to do this or not.
Raising of strings as exceptions, as in the statement
"Error occurred", is deprecated in Python 2.5 and will trigger a
warning. The aim is to be able to remove the string-exception feature
in a few releases.
See About this document... for information on suggesting changes.