Proper exception handling can't wait
Posted : Monday May 25th, 2009

The most overall common mistake I see in Java code posted in forums and discussion groups is bad exception handling. By bad exception handling I mean seeing the following.

In other words, no actual handling of the exception, no printing of the stack trace. Nothing.

When told to fix this it's not uncommon to get back responses like

I know the exception handling is bad but I'm going to fix it later

I find it very difficult to understand the sort of errors in logic that can lead one to make such a statement. But let's clear this up. No. You don't add "better" or "fixed" exception handling later, you add it now.

The fact is that the sort of nonsense posted above is not just useless but actually hides problems from you, and during development and testing, well, you really do want to know about problems. An empty catch block is just laziness but worse a sign of some stupidity because swallowing exceptions only means that you will have no real clue what is working and what is not.

Does that mean you have to do "everything" that you will eventually do in your catch block from the get-go? No. It's okay to improve exception handling later, throwing up dialogs to the user, logging the exception, whatever. But at the very minimum a catch block must always have a call to printStackTrace. That will at least tell you, while you are developing and testing, that a problem actually happened and where it happened.

And if you don't feel like doing that? Then quite simply don't catch the exception at all. Simply add a throws clause to the method and let the exception be propagated to the caller, etc. Quite frankly you can throw right back out of main during testing if you like. It's not perfect but again at least you get a stack trace.

But whatever you do, don't swallow exceptions. Ever. I don't care that you're going to "fix" it later or whatever other lame excuse you have, you simply cannot debug code that swallows exceptions so just don't.

Tags

code  exception  handling 

Categories

Technical  Java 

Comments