No Naked Excepts

You probably shouldn’t be using except: or except Exception: in Python, sometimes called ‘catch-all exceptions’ or ‘naked excepts’.

I’ve tried to find a good article or blog post discussing this, but I haven’t found any thorough discussions of the problems that arise.

Let’s take a look at exceptions. Python is excellent at throwing exceptions, and errs on the side of more exceptions rather than less. For example, this code will raise KeyError:

d = {'foobar': 'Hello world'}
print d['fooba'] # spelling mistake!

The equivalent code in other languages will just return a sentinel value. For example, JavaScript:

var d = {'foobar': 'Hello world'};
console.log(d['fooba']); // prints 'undefined'

The main disadvantage of the JavaScript approach is that it’s easy to get confused when you have your sentinel value in the hashmap. It’s hard to distinguish {} from {'foobar': undefined}.

So, there are a large number of situations that will throw exceptions in Python.

Let’s consider the following piece of Django code, which fetches a page, if it exists.

    page = Page.objects.get(name="home")
except Page.DoesNotExist:
    page = None

This works as expected. However, can you see the mistake in this version?

    page = Page.object.get(name="home")
    page = None

This code will actually throw AttributeError, since Page.object doesn’t exist. However, since we used a catch-all except, we don’t get any error. Subtle bugs like these can be a pain to track down later.

The solution is to always name the specific exception you’re expecting. Note there’s a nasty gotcha with catching multiple exceptions:

except SomeException, OtherException:
    # This only catches SomeException and binds it to
    # the variable OtherException

The correct way to write this is:

except (SomeException, OtherException):
    # the tuple ensures we catch both exceptions

To avoid this gotcha completely, you can either use the excellent Pyflakes to check your code, or use the as syntax:

except (SomeException, OtherException) as e:
    # not using a tuple here is a syntax error

As with every rule, there are a few exceptions. The first is when you’re allowing exceptions to propagate.

    some_resource = open_resource()
    # cleanup resource before propagating exception
    # re-raise the original exception

The other case is long running process, such as daemons:

while True:

In this case, you only want a naked except at the very top level of your program, and you want the exception to go somewhere. I like to log to Sentry or to a log file monitored by Papertrail.

To sum up: Only catch the exceptions you’re expecting to see. For all other exceptions, you want to be informed about it so you can fix it.

Recent Posts

Difftastic, the Fantastic Diff

The Siren Song of Little Languages

How High Are Your Tests?

Helpful: One Year On

The Emacs Guru Guide to Key Bindings