Core Python Programming (2nd Edition)

the exception handler. Although reasons for exceptions are optional, the standard built-in exceptions do
provide at least one argument, an error string indicating the cause of the exception.
Exception parameters can be ignored in the handler, but the Python provides syntax for saving this
value. We have already seen it in the syntax above: to access any provided exception reason, you must
reserve a variable to hold the argument. This argument is given on the except header line and follows
the exception type you are handling. The different syntaxes for the except statement can be extended to
the following:
# single exception
except Exception[, reason]:
suite_for_Exception_with_Argument
# multiple exceptions
except (Exception1, Exception2, ..., ExceptionN)[, reason]:
suite_for_Exception1_to_ExceptionN_with_Argument
reason is a class instance containing diagnostic information from the code raising the exception. The
exception arguments themselves go into a tuple that is stored as an attribute of the class instance, an
instance of the exception class from which it was instantiated. In the first alternate syntax above, reason
is an instance of the Exception class.
For most standard built-in exceptions, that is, exceptions derived from StandardError, the tuple consists
of a single string indicating the cause of the error. The actual exception name serves as a satisfactory
clue, but the error string enhances the meaning even more. Operating system or other environment
type errors, i.e., IOError, will also include an operating system error number that precedes the error
string in the tuple.
Whether a reason contains just a string or a combination of an error number and a string, calling str
(reason) should present a human-readable cause of an error. However, do not lose sight that reason is
really a class instanceyou are only getting the error information via that class's special method __str__
(). We have a complete treatment of special methods as we explore object-oriented programming in
Chapter 13.
The only caveat is that not all exceptions raised in third-party or otherwise external modules adhere to
this standard protocol of error string or error number and error string. We recommend you follow such a
standard when raising your own exceptions (see Core Style note).
Core Style: Follow exception argument protocol
When you raise built-in exceptions in your own code, try to follow the
protocol established by the existing Python code as far as the error
information that is part of the tuple passed as the exception
argument. In other words, if you raise a ValueError, provide the same
argument information as when the interpreter raises a ValueError
exception, and so on. This helps keep the code consistent and will
prevent other applications that use your module from breaking.
The example below is when an invalid object is passed to the float() built-in function, resulting in a
TypeError exception: