Proper use of Exceptions..

Question

Hi all,
I consider myself a fairly competent Java developer. However, and some of you will no doubt say I am not competent for asking this, I can't help but be mystified over the right way to use exception handling. This is a broad question, so let me narrow it down to two specific areas, the UI/client side, and the server side. I am familiar with log4J, JDK 1.4 logging, etc, so I am aware of logging exceptions at runtime for possible use in debugging a problem as well, although this may be yet another topic of discussion... is it good to log exceptions, or should they always be handled and thus never need to be logged?
So, the client/awt/swing application: When and how should they be used? Should I wrap the entire app in a try..catch block that catches Throwable, and throughout my code whereever an exception can occur, allow it to propogate to the main handler? IF so, does that handler do some checks and in some cases display a dialog to the user, and in some cases ignores them? Let's cut out the small things like a NumberFormatException where you convert a string to an int, this and others like it are generally consumed at the spot and not displayed to a user "Hey, somewhere, I tried converting this string to a number and it didn't work..". I know this isn't something you display, at least usually.
I have read that it is better to catch a general exception instead of specific exceptions, and then again I have read the opposite as well. These articles coming from supposed knowledgeable developers, so it throws a monkey wrench in figuring out what is the best way to use them. I have read that if you don't plan on handling it, rethrow it, possibly with an application specific wrapper exception to detail the issue more, OR better yet, add the throws clause and don't even try to handle it so that it gets thrown up the chain of method execution so someone else can handle it. I have read anytime you have the possibility of an exception, catch it and do something right there. So, in the case of a client/swing type of app, what is the rule of thumb?
On the server side it is of course a bit different in that nothing usually gets back to the client, or at least, most shouldn't. If a client accesses EJB that does some logic, such as a DB search and can't find results, no doubt it doesn't need to throw an exception, but instead return null, right? I do realize the scope of this is broad. Is it a client swing/web app talking to EJB via Remote objects, is the servlet in the same JVM as the ejb, does the particular error need to go back to the client, such as no results found, or should it stay, be handled and consumed on the server side? What about the case where you are running a server daemon, something that just continually runs, like an FTP server or something? How are those handled?
Anyway, I would love to really understand the nature of how these should be used in different scenarios. I look forward to some replies, detailed if necessary.
Thank you.

Answer 1

Do NOT ever catch Exception: you lose all granularity and make
maintenance harder.I strongly disagree. 2 good reasons:
1. An error/exception might occur in between 2 operations/changes that must be synched. If one fail, the application must make sure to change back everything that is not consistent within the application.
2. An error on a low level makes no sense to the user. I use to catch exceptions at key-points of the application and restate more informative what has failed.
* Exception chaining/trees
If a bulk operation had multiple failures, the exception that came
back had a dotted list to be displayed to the user.With the new Exception in Java 1.4 forward is excellent for exception-chaining. You could improve that to be a list of errors as stated above or even an exception-tree.
* Informative information
For each exception in an exception chain you could state how informative that exception is, which must of course be done in your own Exception class. Then you might choose to only show the most informative exceptions in the chain.
* Error code
Errocode is good to be able to make a more informative documentation on the side, what different errors are.
* Status / kind
You should also keep track of what kind of exception your application throws, which once again is easier to keep track of in your own exception, eg with a "status" attribute. Then on a FATALERROR you could shut down the program etc.
This Exception may give some ideas (add "informative" attribute etc, make other exceptions inherit this one etc):
public class StatusException extends Exception{
////////////////////// constants ////////////////////////
//Operation successful - probably never used
public final static int SUCCESS=0;
//Operation failed
public final static int FAILURE=1;
//Operation successful, but some information is passed
public final static int INFORMATION=2;
//Operation failed, but retry is encouraged
public final static int AGAIN=3;
//Normal error, eg nullpointerexception
public final static int WARNING=4;
//Internal error, implementation error
public final static int INTERNALERROR=5;
//Serious error, application might need to be restarted
public final static int ERROR=6;
//Serious error and data is corrupted
public final static int FATALERROR=7;
public final static int DEFAULTSTATUS=WARNING;//default status
public final static int GENERALERROR=0;//default error code
///////////////////// attributes ////////////////////////
public int status;
public int errorCode;//a code that is free to use for anything
///////////////////// constructor ///////////////////////
public StatusException(String message, Throwable t, int status, int errorCode) {
super(message,t);
status=_status;
errorCode=_errorCode;
/////////////////////// methods /////////////////////////
public Throwable[] getThrowableTrail(){
ArrayList list=new ArrayList();
Throwable t=this;
while(t!=null){
list.add(t);
t=t.getCause();
Throwable[] trail=new Throwable[list.size()];
list.toArray(trail);
return trail;
Gil