Wandering Thoughts archives

Dangerously over-broad error catching

One of the stock pieces of advice about writing Python code is that basic error checks should be handled by catching the exception that trying to do the operation generates, instead of through explicit checks beforehand. For example, if you are getting the value for a key from a dictionary (what some other languages call a hash), you don't bother checking to see if the key is in the dictionary beforehand; you just try to get the value.

This code might be written like this (especially in examples):

try:
    result = some_func(dict[key])
except KeyError:
    # key isn't in dict.
    result = None

Unfortunately, this code has a serious, somewhat subtle problem; the try: ... except clause is too broad.

You probably wanted result set to None just if dict[key] didn't exist. But with this code, it will also happen if some_func or anything it calls raises an otherwise uncaught KeyError exception. Such uncaught KeyError exceptions are probably real bugs that you want to fix, but this code is hiding them.

You should be doing as little as possible in try/except blocks that catch general errors, because that way you minimize the risk that you're accidentally sweeping unrelated errors under the carpet.

It follows that the worst version of this is to write a try/except block using 'except:' so that it catches all exceptions. Please don't be that lazy.