Finally, a use case for finally – Python Exception Handling

With the help of Bruce Gordon, .NET guru, who gave me a great example that he used to use in his C# classes, I’ve come up with the following Python example, which I think provides a real-world use-case for finally:

import mysql.connector
from mysql.connector import errorcode

config = {
    "user": "username",
    "password": "pwd",
    "host": "127.0.0.1",
    "database": "demodb",
    "raise_on_warnings": True,
}
try:
    cnx = mysql.connector.connect(**config)
    print("OPENED CONNECTION TO DB")
    try:
        cursor = cnx.cursor()
        query = "select name, country from customers"
        cursor.execute(query)
        print("RAN QUERY")
    except:
        print("QUERY FAILED")
        raise
    else:
        for (name, country) in cursor:
            print("-", name, ":", country)
    finally:
        cnx.close()
        print("CLOSED CONNECTION TO DB")
except Exception as e:
    print("Something went wrong:", e)
else:
    print("MORE COOL STUFF TO HAPPEN")

If everything works correctly, this will output:

OPENED CONNECTION TO DB
RAN QUERY
--list of customer names and countries
CLOSED CONNECTION TO DB
MORE COOL STUFF TO HAPPEN

If the connection to the database fails (e.g., because of a bad password), it will output something like:

Something went wrong: 1045 (28000): Access denied for user 
'username'@'localhost' (using password: YES)

In this case, the nested finally clause does not run because the exception occurred in the outer try block. This is what we want. The connection to the database failed to open, so there’s no reason to try to close it.

If the query fails to execute (e.g., because of unknown column name), it will output something like:

OPENED CONNECTION TO DB
QUERY FAILED
CLOSED CONNECTION TO DB
Something went wrong: 1054 (42S22): Unknown column 'name' in 'field
list'

In this case, the finally clause does run because the exception occurred in the inner try block. The connection to the database is successfully made in the outer try block, but the query in the inner try block causes an exception, which we catch and report and re-raise. By re-raising the exception, we can do some more clean up or reporting in the outer except clause and we prevent the outer else clause from running.

I hope this makes sense and is helpful. If anyone has any thoughts on how it could be improved, please let me know.

As an aside, you can download the MySQL Connector/Python used in the example here.