1.7 KiB
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.
-
As called by Pylint. ↩︎