Java exception handling
I've been involved in a couple of discussions about exception handling in Java recently.. and while the discussions were sparked by unrelated topics I came out with one conclusion from both.. People just don't seem to grasp some very basic design ideas when doing error handling..
Number one mistake I see everyone do is..
try
{
....do something here...
}
catch(Exception e)
{
.. handle error
}
Unless you're working on a one-file CS project this is probably not a good idea.. The generic Exception object should only be caught when you *know* what to do with every different type of exception that could occur.. this includes something as basic as a NullPointerException.
In other words.. just catch the exception you can handle and throw everything else up to the calling class.. more often than not it's much more useful information at a higher rather than lower level.
Another mistake.. wrapping an exception inside a new exception and throwing it up the food chain that way.. This may seem like a good idea from the standpoint of clear, easy to understand design.. but by wrapping that exception you're throwing away vital information that the front end could use to handle the error.. It's often appropriate.. but more often not.
In a jist: Only bother with errors you know exactly how to handle.. throw everything else up. Well, of course, unless you're working on front end code.. then that's a whole different story.
Phew.. Java pet peeve #4908983439 :)
Comments
I've done a lot of reading on exceptions but I still can't grasp the absolutely correct way of handling them. Usually I just catch java.lang.Exception on the EJB side, wrap it up in a RemoteException and pass it on so that the error is displayed on the client side. Is this okay? I mean what's the point of catching ParseException specifically, just to once again wrap it up and pass it to the client side? It seems I would do the same thing in both cases. And if I don't pass it on to the client side, my bean would hang up, with no message on the dient side to indicate a problem.
Maybe on the client side (interface wise), catching a ParseException and displaying an error message makes more sense, but I'm not sure if my methods are good programming practice. Can anyone suggest a better way of handling server-side and client-side exceptions?
Posted by: kerneljack | June 2, 2003 05:22 AM
Where wrapping of exceptions is required I get really annoyed when people don't pass along the wrapped exception in the constructor of the wrapping exception.
In Java 1.4 all Exception types take a root cause in their constructors so there's no longer an excuse for this.
Pah!
Posted by: Darren Greaves | June 2, 2003 04:34 PM
Even worse is "catch (Throwable t)" peppered throughout the code... what can the average program possibly do with an OutOfMemoryError or a VirtualMachineError?
PS: I like the phrase "throwing it up the food-chain". Sounds like a food fight at McDonalds. Hmmm... new GherkinException() anybody?
Posted by: Alan Green | June 2, 2003 06:52 PM
I actually read a conversation on WikiWikiWeb defending this practice, and saying throwing exceptions was a bad idea (or a CodeSmell, whatever you want to call it). Simply unbelievable.
The horrible thing in my opinion is when a call is made that can throw an exception and this happens:
try
{
doSomething();
} catch (Exception e)
{
throw new RuntimeException(e.getMessage());
}
Drives me. Up. The. Wall.
Posted by: Will Sargent | June 7, 2003 04:18 AM