Python 101 (part 8): An Exceptionally Clever Snake

In this concluding article of the Python 101 series, find out how to use Python’s exception-handling routines to trap and resolve program errors, learn to generate and use custom error messages, and get acquainted a bunch of useful (and free!) Python resources online.

If you’ve been following along since the beginning, I think you’ll agree with me that it’s certainly been an interesting eight weeks.

Together, we’ve visited all the standard attractions – we’ve thumbed through the rulebook for strings, numbers, lists, dictionaries and those oddly-named tuples; mucked around with system files and directories; packaged code into functions and functions into modules; and dissected the Python interpreter and some of Python’s innumerable built-in functions - and indulged in some decidedly non-standard activities – learning the names of exotic Italian dishes; stomping on all kinds of creepy-crawlies; attempting to con unwitting customers into purchasing air in a bottle; and hooking up with old flames, new superheroes and the complete cast of “Star Wars”.

In this concluding article, I’m going to be demonstrating Python’s error-handling routines, and showing you how to wrap your code in them to avoid violent – and potentially embarrassing – flame-outs. I’ll be explaining the different types of errors you might encounter and the Python constructs available to manage them, with examples that demonstrate just how powerful this capability really is.

Talk about getting your money’s worth!{mospagebreak title=Anatomy Of An Exception} No developer, no matter how good (s)he is, writes bug-free code all the time. Which is why most programming languages – including Python – come with built-in capabilities to catch errors and take remedial action. This action could be something as simple as displaying an error message, or as complex as heating your computer’s innards until they burst into flame (just kidding!)

Normally, when a Python program encounters an error, be it syntactical or logical, it exits the program at that stage itself with a message indicating the cause of the error. Now, while this behaviour is acceptable during the development phase, it cannot continue once a Python program has been released to actual users. In these “live” situations, it is unprofessional to display cryptic error messages (which are usually incomprehensible to non-technical users); rather, it is more professional to intercept these errors and either resolve them (if resolution is possible), or notify the user with a clear error message (if not).

The term “exceptions” refers to those errors which can be tracked and controlled. For example, if a function attempts an unsupported operation on a built-in Python object (say, modifying an immutable object), Python will generate a “TypeError” exception, together with a stack trace or detailed explanation of the problem. Exceptions like these can be caught by the application, and appropriately diverted to an exception-handling routine.

An example might make this clearer. Consider the following Python program,

#!/usr/bin/python

# set up tuple dessert = ('apple pie', 'chocolate fudge cake', 'icecream')

# change tuple value dessert[1] = 'chocolate brownies'
which generates a TypeError because I’m trying to modify a tuple.

Traceback (innermost last): File "dessert.py", line 5, in ? dessert[1] = 'chocolate brownies' TypeError: object doesn't support item assignment
Now, let’s add some code to trap and handle the exception gracefully.

#!/usr/bin/python

try: # try running this code dessert = ('apple pie', 'chocolate fudge cake', 'icecream') dessert[1] = 'chocolate brownies' except TypeError: # if error, do this... print "Whoops! Something bad just happened. Terminating script."
And this time, when the script is executed, it will not generate a TypeError – instead, it will output

Whoops! Something bad just happened. Terminating script.
This is a very basic example of how Python exceptions can be trapped, and appropriate action triggered. As you will see, the ability to handle errors in a transparent manner throws open some pretty powerful possibilities…{mospagebreak title=Trying Harder} Python offers two flavours of exception handler – the first is the “try-except” construct you just saw, while the second is the “try-finally” construct.

The “try-except” construct – actually the “try-except-else” construct - allows developers to trap different types of errors and execute appropriate exception-handling code depending on the exception type. It’s a lot like the “if-elif-else” conditional construct, allowing for the execution of different code blocks depending on the type of error generated.

The structure of a “try-except-else” block looks like this:

try: execute this block except err1: execute this block if exception "err1" is generated except err2: execute this block if exception "err2" is generated

... and so on ...

else: execute this block
When Python encounters code wrapped within a “try-except-else” block, it first attempts to execute the code within the “try” block. If this code is processed without any exceptions being generated, Python checks to see if the optional “else” block is present. If it is, the code within it is executed.

If an exception is encountered while running the code within the “try” block, Python stops execution of the “try” block at that point and begins checking each “except” block to see if there is a handler for the exception. If a handler is found, the code within the appropriate “except” block is executed; if not, control either moves to the parent “try” block, if one exists, or to the default handler, which terminates the program and displays a stack trace.

Once the “try” block has been executed and assuming that the program has not been terminated, the lines following the “try” block are executed.

Let’s illustrate this with a simple Python program, which accepts two numbers and attempts to divide them by each other.

#!/usr/bin/python

alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma
Now look what happens when I run this with different values.

Gimme a number: 10 Gimme another number: 2 10 divided by 2 is 5

Gimme a number: 10 Gimme another number: 0 Traceback (innermost last): File "div.py", line 6, in ? gamma = alpha / beta ZeroDivisionError: integer division or modulo

Gimme a number: 67347328 Gimme another number: 943282646373739 Traceback (innermost last): File "div.py", line 4, in ? beta = input("Gimme another number: ") OverflowError: integer literal too large

Let’s now add a couple of exception handlers to this code, so that it knows how to gracefully handle errors like the ones above:

#!/usr/bin/python

try: alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma except ZeroDivisionError: print "Cannot divide by zero!" except OverflowError: print "Number too large!" else: print "No errors encountered!"

print "-- All done --"
And now let’s try the different test cases above again:

Gimme a number: 10 Gimme another number: 2 10 divided by 2 is 5 No errors encountered! -- All done --

Gimme a number: 10 Gimme another number: 0 Cannot divide by zero! -- All done --

Gimme a number: 823748237 Gimme another number: 234378264732647326476327 Number too large! -- All done --

Depending on the type of error encountered, the appropriate exception handler is triggered and an error message displayed. The optional “else” block is executed at the end of the script *only* if no exceptions are encountered.

Once an exception has been caught and resolved, the remainder of the “try” block is ignored and Python executes the lines following the entire “try-except-else” block.{mospagebreak title=Different Strokes} You can use a single “except” statement to handle more than one error by separating the various exception names with commas and enclosing them in parentheses. Modifying the example above, we have

#!/usr/bin/python

try: alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma except (ZeroDivisionError, OverflowError): print "You entered an illegal value!" else: print "No errors encountered!"

print "-- All done --"
If you take a close look at the stack trace on the previous page, you’ll see that when Python encounters an exception, it prints both an exception name and a descriptive string explaining the error.

ZeroDivisionError: integer division or modulo

OverflowError: integer literal too large

This descriptive text can also be caught and used by an exception handler, if you define a variable to store it in the “except” statement. Consider the following code:

#!/usr/bin/python

try: alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma except ZeroDivisionError, desc: print "Illegal value (", desc, ")" except OverflowError, desc: print "Illegal value (", desc, ")" else: print "No errors encountered!"

print "-- All done --"
In this case, the “desc” variable in the exception handler stores the descriptive error message generated by Python; this variable may then be used within the handler.

Here’s the output:

Gimme a number: 10 Gimme another number: 5 10 divided by 5 is 2 No errors encountered! -- All done --

Gimme a number: 10 Gimme another number: 0 Illegal value ( integer division or modulo ) -- All done --

Gimme a number: 897475834785348534785 Illegal value ( integer literal too large ) -- All done --

This works even if your exception handler is handling more than one exception.

#!/usr/bin/python

try: alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma except (ZeroDivisionError, OverflowError), desc: print "Illegal value (", desc, ")" else: print "No errors encountered!"

print "-- All done --"
Now, the “try” statement can only deal with exceptions that it knows about. What about the ones the developer can’t predict?

Gimme a number: 76 Gimme another number: abc Traceback (innermost last): File "div.py", line 5, in ? beta = input("Gimme another number: ") File "gt;", line 0, in ? NameError: abc
It’s possible to use a general “except” statement to handle *any* type of exception generated by the interpreter – simply omit the exception name from the “except” statement. The following code snippet illustrates this technique:

#!/usr/bin/python

try: alpha = input("Gimme a number: ") beta = input("Gimme another number: ") gamma = alpha / beta print alpha, "divided by", beta, "is", gamma except: pass

print "-- All done --"
In this case, it doesn’t matter what type of exception Python generates - the generic handler will catch it, ignore it and continue to process the rest of the script.

Gimme a number: asd -- All done --

Gimme a number: 10 Gimme another number: 0 -- All done --

Gimme a number: 58439058349058934859 -- All done --

Gimme a number: 10 Gimme another number: 2 10 divided by 2 is 5 -- All done --

It should be noted, however, that this approach, although extremely simple, is *not* recommended for general use. It is poor programming practice to trap all errors, regardless of type, and ignore them; it is far better - and more professional – to anticipate the likely errors ahead of time, and use the “try-except” construct to isolate and resolve them.{mospagebreak title=Passing The Buck} If one exception handler is nested within another, Python typically uses the one closest to where the exception occurs. To illustrate this, consider the following code snippet:

#!/usr/bin/python

# nested_handlers.py

def popeye(): try: olive() except NameError: print "Error in popeye"

def olive(): try: print someUnnamedVar except NameError: print "Error in olive"

try: popeye() except NameError: print "Error in main"
In this case, there are three exception handlers defined for the same type of exception. The outermost one is in the main program body, the next is within the popeye() function called from the main script, and the third is within the olive() function called by popeye().

When olive() runs, it generates a “NameError” exception, which is immediately handled by its own “try” block.

$ nested_handlers.py Error in olive
However, if olive() didn’t have a “try” block, or its “try” block didn’t account for “NameError” exceptions,

#!/usr/bin/python

def popeye(): try: olive() except NameError: print "Error in popeye"

def olive(): print someUnnamedVar

try: popeye() except NameError: print "Error in main"
the exception would be passed up to the previous level, the calling popeye() function, which would generate

$ nested_handlers.py Error in popeye
If popeye()’s exception handler didn’t have the ability to handle the exception, the exception would move up even further, to the main body of the script,

#!/usr/bin/python

def popeye(): try: olive() # this wouldn't handle NameError except IndexError: print "Error in popeye"

def olive(): print someUnnamedVar

try: popeye() except NameError: print "Error in main"
which would result in

$ nested_handlers.py Error in main
And if there weren’t any handlers capable of resolving the error,

#!/usr/bin/python

def popeye(): olive()

def olive(): print someUnnamedVar

popeye()
the exception would be processed by the default handlers, which would kill the script and print a stack trace.

Traceback (innermost last): File "./test.py", line 9, in ? popeye() File "./test.py", line 4, in popeye olive() File "./test.py", line 7, in olive print someUnnamedVar NameError: someUnnamedVar
{mospagebreak title=Bad Boys} Most of what you’ve just learned also applies to Python’s other exception-handlng construct, the “try-finally” statement. The “try-finally” statement block differs from “try-except-else” in that it merely detects errors; it does not provide for a mechanism to resolve them. It is typically used to ensure that certain statements are always executed when an error (regardless of type) is encountered.

The “try-finally” statement block looks like this:

try: execute this block finally: if exceptions generated, execute this block
If an exception is encountered when running the code within the “try” block, Python will stop execution at that point; jump to the “finally” block; execute the statements within it; and then pass the exception upwards, to the parent “try” block, if one exists, or to the default handler, which terminates the program and displays a stack trace.

Here’s an example:

#!/usr/bin/python

dessert = ('apple pie', 'chocolate fudge cake', 'icecream')

try: # generate error by accessing index out of range print dessert[10] finally: print "Something bad happened"
When this program runs, an IndexError exception will be generated and the “finally” block will execute, printing an error message. Control will then flow to the parent exception handler, which is the Python interpreter in this case; the interpreter will terminate the program and print a stack trace.

$ dessert.py Something bad happened Traceback (innermost last): File "dessert.py", line 7, in ? print dessert[10] IndexError: tuple index out of range
Since “try-finally” blocks simply detect errors, passing the resolution buck upwards to the parent “try” block, it’s possible to nest them within “try-except-else” blocks. Take a look:

#!/usr/bin/python

try: dessert = ('apple pie', 'chocolate fudge cake', 'icecream')

try: # generate error by accessing index out of range print dessert[10] finally: print "Something bad happened"

except IndexError: print "You attempted to access a non-existent element. Bad boy!" except NameError: print "You attempted to access a non-existent object. What are you thinking?"
Here’s what’ll happen when you run it:

Something bad happened You attempted to access a non-existent element. Bad boy!
{mospagebreak title=Raising The Bar} Thus far, you’ve been working with Python’s built-in exceptions, which can handle most logical or syntactical expressions. However, Python also allows you to get creative with exceptions, by generating your own custom exceptions if the need arises.

This is accomplished via Python’s “raise” statement, which is used to raise errors which can be detected and resolved by the “try” family of exception handlers. The “raise” statement needs to be passed an exception name, and an optional descriptive string. When the exception is raised, this exception name and description will be made available to the defined exception handler.

Let’s go to a quick example – the line of code

raise ValueError, "What on earth are you thinking?!"
generates the following error.

Traceback (innermost last): File "./test.py", line 3, in ? raise ValueError, "What on earth are you thinking?!" ValueError: What on earth are you thinking?!
You can also name and use your own exceptions.

#!/usr/bin/python

import os

# define error object error = "someError"

# function to raise error def checkName(name): if (name != os.environ["USER"]): raise error, "Username mismatch!"

name = raw_input("Enter your system username: ") checkName(name)
In this case, if the username entered at the prompt does not match the name stored in the environment variable $USER, Python will raise a user-defined exception named “someError”, with a string of text describing the nature of the error. Take a look:

Enter your system username: john Traceback (innermost last): File "checkuser.py", line 16, in ? checkName(name) File "checkuser.py", line 11, in checkName raise error, "Username mismatch!" someError: Username mismatch!
Note that the exception must be assigned to an object in order for it to work correctly.

# define error object error = "someError"
Trapping user-defined errors is exactly the same as trapping pre-defined Python errors. The following refinement of the code above illustrates this:

#!/usr/bin/python

import os

# define error object error = "someError"

# function to raise error def checkName(name): if (name != os.environ["USER"]): raise error, "Username mismatch!"

# try this code try: name = raw_input("Enter your system username: ") checkName(name) except error, desc: print desc
Here’s the output of the script above, when the wrong username is entered.

Enter your system username: john Username mismatch!
{mospagebreak title=Strong Pythons (And The Exceptions That Love Them)} A number of standard exceptions are built into Python – here’s a list of the most common ones.

IOError – generated when an I/O operation fails;

ImportError – generated when a module import fails

IndexError – generated when an attempt is made to access a non-existent element index;

KeyError – generated when an attempt is made to access a non-existent dictionary key;

MemoryError – generated when an out-of-memory error occurs;

NameError – generated when an attempt is made to access a non-existent variable;

SyntaxError – generated when the interpreter finds a syntax error;

TypeError – generated when an attempt is made to run an operation on an incompatible object type;

ZeroDivisionError – generated when an attempt is made to divide by zero.

For a complete list, take a look at http://www.python.org/doc/current/lib/module-exceptions.html{mospagebreak title=The End Of The Affair} And that just about brings the curtain down on this series of tutorials. I hope you’ve enjoyed reading these articles as much as I’ve enjoyed writing them, and that you now have a better understanding of the wonder that is Python.

Should you need more information on the topics covered in this tutorial, please consider visiting the following Web sites:

The official Python Web site, at http://www.python.org/

The Python Cookbook, at http://aspn.activestate.com/ASPN/Cookbook/Python

The Vaults of Parnassus, at http://www.vex.net/parnassus/

Jython (Python+Java), at http://www.jython.org/

Python HOWTOs, at http://py-howto.sourceforge.net/

The Python FAQ, at http://www.python.org/doc/FAQ.html

The Python Quick Reference, at http://starship.python.net/quick-ref1_52.html

As for me, I’ll be back soon to talk about object-oriented programming and Web development with Python – so keep an eye out for those articles. Until then, though, stay healthy…and thanks for watching!

Note: All examples in this article have been tested on Linux/i586 with Python 1.5.2. Examples are illustrative only, and are not meant for a production environment. YMMV!
[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan