PHP Architecture Overview
Client 2Adding Error Checking
If you look back to line 7 of Listing 17.1, you'll notice that client1 calls pgdb.connect() to connect to a PostgreSQL server. If anything goes wrong during this function call, Python will print a stack trace and abort the program.
If you want to intercept a connection error, you must wrap the call to pgdb. connect() in a TRy/except block. The Python DB-API specification defines a hierarchy of exception types that a conforming implementation may throw. The most general exception type is StandardError. All other DB-API exceptions are derived (directly or indirectly) from StandardError.
Listing 17.2 shows client2.py. This client calls pgdb.connect() inside of a try/except block and catches any exceptions derived from StandardError (including StandardError).
Listing 17.2. client2.py
1 #!/usr/bin/python 2 # 3 # Filename: client2.py 4 5 import pgdb 6 import sys 7 8 try: 9 connection = pgdb.connect( database = "movies", 10 user = "bruce", 11 password = "cows" ) 12 print connection 13 14 except StandardError, e: 15 print str( e ) 16 17 except: 18 exception = sys.exc_info() 19 20 print "Unexpected exception:" 21 print " type : %s" % exception[0] 22 print " value: %s" % exception[1]
client2 includes two except clauses that catch any exception thrown by pgdb.connect(). The first except clause will catch any exception derived from StandardError. The second catches exceptions derived from any other class. When you catch an exception that has not been derived from StandardError, you can use the sys.exc_info() function to obtain information about the exception. sys.exc_info() returns a tuple with three values: exception[0] contains the name of the exception type, exception[1] contains the exception parameter (usually an error message), and exception[2] contains a traceback object. client2 prints the exception type and parameter:
$ ./client2.py could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
The Python DB-API describes the exception types shown in Table 17.1.
Exception Type |
Derived From |
Thrown By |
---|---|---|
Warning |
StandardError |
Not used |
Error |
StandardError |
Not used |
InterfaceError |
Error |
execute() executemany() |
DatabaseError |
Error |
execute() executemany() |
DataError |
DatabaseError |
Not used |
OperationalError |
DatabaseError |
execute() executemany() commit() rollback() cursor() connect() |
IntegrityError |
DatabaseError |
Not used |
InternalError |
DatabaseError |
Not used |
ProgrammingError |
DatabaseError |
Not used |
NotSupportedError |
DatabaseError |
Not used |
The first column in Table 17.1 shows the name of each exception. The middle column shows the parent type for each exception. The final column shows the name of each PostgreSQL/DB-API function that throws the exception.
It's important to remember that the DB-API functions can throw exceptions other than the ones listed in Table 17.1 (syntax errors, invalid data type errors, and so on). It's usually a good idea to catch specific exceptions that you expect to see with a typed except clause and catch unexpected exceptions with an untyped except. That's what we've done in client2.py. The first except (at line 14) catches exceptions derived from StandardError. The second, at line 17, catches all other exceptions.
Now, you have a client application that establishes a connection or reports an error if the connection attempt fails. It's time to do something a little more interesting.