| The rest of the line provides detail based on the type of exception and what |
| caused it. |
| |
| The preceding part of the error message shows the context where the exception |
| happened, in the form of a stack traceback. In general it contains a stack |
| traceback listing source lines; however, it will not display lines read from |
| standard input. |
| |
n | The Python Library Reference (XXX reference: ../lib/module-exceptions.html) |
n | :ref:`bltin-exceptions` lists the built-in exceptions and their meanings. |
| lists the built-in exceptions and their meanings. |
| |
| |
| .. _tut-handling: |
| |
| Handling Exceptions |
| =================== |
| |
| It is possible to write programs that handle selected exceptions. Look at the |
| is signalled by raising the :exc:`KeyboardInterrupt` exception. :: |
| |
| >>> while True: |
| ... try: |
| ... x = int(raw_input("Please enter a number: ")) |
| ... break |
| ... except ValueError: |
| ... print "Oops! That was no valid number. Try again..." |
n | ... |
n | ... |
| |
| The :keyword:`try` statement works as follows. |
| |
| * First, the *try clause* (the statement(s) between the :keyword:`try` and |
| :keyword:`except` keywords) is executed. |
| |
| * If no exception occurs, the *except clause* is skipped and execution of the |
| :keyword:`try` statement is finished. |
| the exception (allowing a caller to handle the exception as well):: |
| |
| import sys |
| |
| try: |
| f = open('myfile.txt') |
| s = f.readline() |
| i = int(s.strip()) |
n | except IOError, (errno, strerror): |
n | except IOError as (errno, strerror): |
| print "I/O error(%s): %s" % (errno, strerror) |
| print "I/O error({0}): {1}".format(errno, strerror) |
| except ValueError: |
| print "Could not convert data to an integer." |
| except: |
| print "Unexpected error:", sys.exc_info()[0] |
| raise |
| |
| The :keyword:`try` ... :keyword:`except` statement has an optional *else |
| clause*, which, when present, must follow all except clauses. It is useful for |
| The except clause may specify a variable after the exception name (or tuple). |
| The variable is bound to an exception instance with the arguments stored in |
| ``instance.args``. For convenience, the exception instance defines |
| :meth:`__getitem__` and :meth:`__str__` so the arguments can be accessed or |
| printed directly without having to reference ``.args``. |
| |
| But use of ``.args`` is discouraged. Instead, the preferred use is to pass a |
| single argument to an exception (which can be a tuple if multiple arguments are |
n | needed) and have it bound to the ``message`` attribute. One my also instantiate |
n | needed) and have it bound to the ``message`` attribute. One may also |
| an exception first before raising it and add any attributes to it as desired. :: |
| instantiate an exception first before raising it and add any attributes to it as |
| desired. :: |
| |
| >>> try: |
| ... raise Exception('spam', 'eggs') |
n | ... except Exception, inst: |
n | ... except Exception as inst: |
| ... print type(inst) # the exception instance |
| ... print inst.args # arguments stored in .args |
| ... print inst # __str__ allows args to printed directly |
| ... x, y = inst # __getitem__ allows args to be unpacked directly |
| ... print 'x =', x |
| ... print 'y =', y |
| ... |
n | <type 'instance'> |
n | <type 'exceptions.Exception'> |
| ('spam', 'eggs') |
| ('spam', 'eggs') |
| x = spam |
| y = eggs |
| |
| If an exception has an argument, it is printed as the last part ('detail') of |
| the message for unhandled exceptions. |
| |
| Exception handlers don't just handle exceptions if they occur immediately in the |
| try clause, but also if they occur inside functions that are called (even |
| indirectly) in the try clause. For example:: |
| |
| >>> def this_fails(): |
| ... x = 1/0 |
n | ... |
n | ... |
| >>> try: |
| ... this_fails() |
n | ... except ZeroDivisionError, detail: |
n | ... except ZeroDivisionError as detail: |
| ... print 'Handling run-time error:', detail |
n | ... |
n | ... |
| Handling run-time error: integer division or modulo by zero |
| |
| |
| .. _tut-raising: |
| |
| Raising Exceptions |
| ================== |
| |
| NameError: HiThere |
| |
| The first argument to :keyword:`raise` names the exception to be raised. The |
| optional second argument specifies the exception's argument. Alternatively, the |
| above could be written as ``raise NameError('HiThere')``. Either form works |
| fine, but there seems to be a growing stylistic preference for the latter. |
| |
| If you need to determine whether an exception was raised but don't intend to |
n | handle it, a simpler form of the :keyword:`raise` statement allows you to re- |
n | handle it, a simpler form of the :keyword:`raise` statement allows you to |
| raise the exception:: |
| re-raise the exception:: |
| |
| >>> try: |
| ... raise NameError, 'HiThere' |
| ... except NameError: |
| ... print 'An exception flew by!' |
| ... raise |
| ... |
| An exception flew by! |
| Exceptions should typically be derived from the :exc:`Exception` class, either |
| directly or indirectly. For example:: |
| |
| >>> class MyError(Exception): |
| ... def __init__(self, value): |
| ... self.value = value |
| ... def __str__(self): |
| ... return repr(self.value) |
n | ... |
n | ... |
| >>> try: |
| ... raise MyError(2*2) |
n | ... except MyError, e: |
n | ... except MyError as e: |
| ... print 'My exception occurred, value:', e.value |
n | ... |
n | ... |
| My exception occurred, value: 4 |
| >>> raise MyError, 'oops!' |
| Traceback (most recent call last): |
| File "<stdin>", line 1, in ? |
| __main__.MyError: 'oops!' |
| |
| In this example, the default :meth:`__init__` of :class:`Exception` has been |
| overridden. The new behavior simply creates the *value* attribute. This |
| self.next = next |
| self.message = message |
| |
| Most exceptions are defined with names that end in "Error," similar to the |
| naming of the standard exceptions. |
| |
| Many standard modules define their own exceptions to report errors that may |
| occur in functions they define. More information on classes is presented in |
n | chapter :ref:`tut-classes`, "Classes." |
n | chapter :ref:`tut-classes`. |
| |
| |
| .. _tut-cleanup: |
| |
| Defining Clean-up Actions |
| ========================= |
| |
| The :keyword:`try` statement has another optional clause which is intended to |
| define clean-up actions that must be executed under all circumstances. For |
| example:: |
| |
| >>> try: |
| ... raise KeyboardInterrupt |
| ... finally: |
| ... print 'Goodbye, world!' |
n | ... |
n | ... |
| Goodbye, world! |
| Traceback (most recent call last): |
| File "<stdin>", line 2, in ? |
| KeyboardInterrupt |
| |
| A *finally clause* is always executed before leaving the :keyword:`try` |
| statement, whether an exception has occurred or not. When an exception has |
| occurred in the :keyword:`try` clause and has not been handled by an |
| :keyword:`except` clause (or it has occurred in a :keyword:`except` or |
| :keyword:`else` clause), it is re-raised after the :keyword:`finally` clause has |
| been executed. The :keyword:`finally` clause is also executed "on the way out" |
| when any other clause of the :keyword:`try` statement is left via a |
| :keyword:`break`, :keyword:`continue` or :keyword:`return` statement. A more |
n | complicated example:: |
n | complicated example (having :keyword:`except` and :keyword:`finally` clauses in |
| the same :keyword:`try` statement works as of Python 2.5):: |
| |
| >>> def divide(x, y): |
| ... try: |
| ... result = x / y |
| ... except ZeroDivisionError: |
| ... print "division by zero!" |
| ... else: |
| ... print "result is", result |
| Traceback (most recent call last): |
| File "<stdin>", line 1, in ? |
| File "<stdin>", line 3, in divide |
| TypeError: unsupported operand type(s) for /: 'str' and 'str' |
| |
| As you can see, the :keyword:`finally` clause is executed in any event. The |
| :exc:`TypeError` raised by dividing two strings is not handled by the |
| :keyword:`except` clause and therefore re-raised after the :keyword:`finally` |
t | clauses has been executed. |
t | clause has been executed. |
| |
| In real world applications, the :keyword:`finally` clause is useful for |
| releasing external resources (such as files or network connections), regardless |
| of whether the use of the resource was successful. |
| |
| |
| .. _tut-cleanup-with: |
| |