Java has a pretty powerful mechanism of error handling. But sometime programmers ignore it. Recently I’ve seen the following post in one of the production support chat rooms:
Developers, please don’t do this:
} catch (IOException e) { //do nothing, just ignore it } finally {
this is better:
} catch (IOException e) { logger.error(e,e); } finally {
The poster of this message has demonstrated what being overly polite means. I’m not as polite as the guy who wrote this and want to say that Java developers who quietly ignore exceptions should be tracked down and fired. They can be considered terrorists who plant time bombs into applications.
Handling programming errors is a must. Writing an empty catch clause is the worst thing that could be done. It’s like a time bomb that will definitely blow the program up one day, and finding such bombs is usually a time consuming process. Some people want to save a couple of seconds required to log the error, which eventually will cost dearly to the QA and support teams. Don’t cut corners, exception handling should be taken very seriously if you consider yourself a professional software developer.
yakovfain.com 
If I could I would fire every developer I see doing that thing.
The problem is that almost all my coworkers wrote at least once that horrible exception swallowing.
The problem is that IOException should never have been made a checked exception. There are some cases where the immediate caller can handle it, but more times than not it just means the program itself is in an error state, meaning it should be handled way up the callstack.
Similar time bomb is conditionals without a default. e.g.,
x = some value coming from db
if (x == val1) {
do x;
} else if (x == val2) {
do y;
}
I am having a tough time with majority of developers to convince them about the need to have a catch-all else. Often the arguments are –
(i) there are only two possible values for x, val1 and val2 and I have covered them well.
(ii) at present, only these two values exist in db. We can’t code for ‘future’ unknown values.
(iii) there is no requirement saying what to do when x is something else then val1 or val2.
The last argument is the worst since the blame is transferred to business!
Yes, this is a nice addition to the collection of time bombs. Anyone else wants to contribute?
Side-effects in getter methods – non-idempotent changes to object state when property has been read. It’s the anti-personnel mine for anyones who try to optimize unnecessary duplicate condition checks in if/loops.