I had some discussion recently about the evils of using a naked except:. Here is a more complete description of the dangers, and of the correct solutions.
In short, except: is bad because hides the source source of the exception and frustrates debugging. For example, consider this code:
try: parsed = parse(file_name) except: raise ParseError("can't parse file")
It will likely produce an error something like this:
$ ./my_program.py Traceback (most recent call last): ... ParseError: can't parse file
This kind of error makes me want to high-five someone. In the face. With a chair.
Notice that it does not contain any information about:
- The file which caused the error
- The line which caused the error
- The nature of the error (is it an expected error? A bug? Who knows!)
And tracking down the source of this error would likely involve some binary searching on the input file or dropping into a debugger.
These are some other, equally unhelpful, bits of code that I have seen:
# There isn't much worse than completely hiding the error except: pass # Almost as bad is not giving any hit at what it was except: print "there was an error!" # And even showing the original error can be unhelpful if the error is # something like an IndexError which could come from anywhere except Exception, e: raise MyException("there was an error: %r" %(e, ))
Now, there is a situations where using a naked except: can be used safely. Exactly one.
1. The except: block is terminated with a raise
For example, when some cleanup needs to be done before leaving the function:
cxn = open_connection() try: use_connection(cxn) except: close_connection(cxn) raise
(note that, usually, the finally: block should be used for this kind of cleanup, but there are some situations where the code above makes more sense)
Every other situation should use except Exception, e::
2. A new exception is raised but the original stack trace is used
try: parsed = parse(file_name) except Exception, e: raise ParseError("error parsing %r: %r" %(file_name, e)), None, sys.exc_info()
A few things to note: first, the three expression version of raise is used, the third of which being the current stack trace. This means that the stack trace will point to the original source of the error:
File "my_program.py", line 9, in <module> parse(file_name) File "parser.py", line 2, in parse for lineno, line in enumerate(open(file_name), "rb"): ParseError: error parsing 'input.bin': TypeError("'str' object cannot be interpreted as an index",)
Instead of the (less helpful) line which re-raised the error:
File "my_program.py", line 11, in <module> raise ParseError("error parsing %r: %r" %(file_name, e)) ParseError: error parsing 'input.bin': TypeError("'str' object cannot be interpreted as an index",)
Second, the error includes the file name and original exception, which will make debugging significantly easier. When I'm writing particularly fragile code I'll often wrap the entire block in a try/except which will include as much state as is sensible in the error. For example, the main loop of the parse function might be:
def parse(file_name): lineno = -1 current_foo = None try: f = open(file_name) for lineno, line in enumerate(f): current_foo = line.split() ... except Exception, e: raise ParseError("error while parsing %r (line %r; current_foo: %r): %r" %(file_name, lineno, current_foo, e)), None, sys.exc_info()
3. The exception and stack trace are logged
For example, the main runloop of an application might be:
while 1: try: do_stuff() except Exception, e: log.exception("error in mainloop") time.sleep(1)
A few things to note: first, a naked except: should not be used here, as it will also catch KeyboardInterrupt and SystemExit exceptions, which is almost certainly a bad thing.
Second, log.exception is used, which includes a complete stack trace in the log (care should also be taken to make sure that these logs will be checked - for example by sending an email on exception logs).
Third, the time.sleep(1) ensures that the system won't get clobbered if the do_stuff() function immediately raises an exception.