Things I Learnt The Hard Way - It's Better To Let The Application Crash Than Do Nothing

Although that sounds weird, it's better to not add any error handling than silently capturing errors and doing nothing.

For example, a (sadly common) example of Java code:

try {
  something_that_can_raise_exception()
} catch (Exception ex) {
  System.out.println(ex);
}

This does nothing to deal with the exception -- besides printing it, that is.

The example may be a bit bad, 'cause Java forces capturing exceptions on functions that throw exceptions and it forces functions to mark themselves as throwing exceptions if there a throw in them.

But Python doesn't have this restriction and people still try to capture exceptions for doing absolutely nothing -- and, worse, just keep the execution going.

If the language allows it, you should let the application crash due the lack of error handling -- as long as you don't have any idea on how to handle it. Then, when they crash, you can think of a way to deal with it, instead of silently capturing it and doing nothing.

Also, keep in mind to not go forth and capture every exception/error in a single take -- like the example above, which will capture every exception, or like except Exception in Python. This last example actually happened to me when another developer added this "broad except"1 in a network code and, at some point, the code would get into the capture all the time. We checked every cable, every connection, every interface, till I noticed there was a syntax error in the code. In Python, syntax errors raise exceptions and, because we had a "capture all exceptions", we lost some pretty good time looking for the problem in the wrong place.

1

As called by Pylint.

<< Beware of Interface Changes
 
If You Know How To Handle It, Handle It >>