Exception Handling

Exception handling is one of the good features of Java and C#, which is highly abused. The following are the questions that one should ask, while working with exceptions.

If you are catching an exception, and throwing it without taking any action, why do you need to catch an exception in the first place?

If you are opening a resource, and if you must close the resource once it is done, how do you make sure that, the resources are always closed?

The following is the best way to handle this.

open connection
try {
    Use connection
} finally {
    close connection
}

Let's suppose, if you have opened two resources, then many people try to do like below.

Declare Resource1
Declare Resource2
try {
    Open Resource1
    Open Resource2
    Use both the resources
} finally {
    if(Resource1 != null)
        Close Resource1;
    if(Resource2 != null)
        Close Resource2;
}

There is a problem in the above code. If closing of Resource1 throws any exception, then Resource2 will not be closed. The better way to do this is,

Open Resource1
try {
    Open Resource2
    try {
        Use both the resources
    } finally {
        Close Resource2
    }
} finally {
    Close Resource1;
}

If you have multiple resources, then the nesting level will increase. But, that is not a problem. Having single try finally block gives problems in case of failures. For any general database query, there would be three try finally blocks (For Connection, Statement and ResultSet). It is always a best practice to have try finally blocks for each resource you are opening.

If you are developing a library, which can be used by many others.

If you are getting an unexpected exception from another library, why do you want to catch it? Why not throw it without catching?

For example, you are developing a library to return some data from the database. Let's suppose, you are trying to open a database connection from a configuration file, and it throws an exception. Why do you want to handle it? Why not throw it to the upper layer, and let it handle. If you are planning to catch it, log it, and rethrow it, are you sure that, it is fine with all the developers who use that library. If all the components are logging essentially the same error, won't the logging become cluttered. Few developers who use that library, may not want any logging from that library. If you are planning to catch it, and return some error code, don't you think significant information is lost while doing that? Can you come up with all the error cases while connecting to a database? It is possible that, the error is because of not having the configuration file, having the invalid database name, database server, user name, password, or not having access to the db, or it can be anything. Why do you want to capture all those in your code? Let the upper layer decide on what to do. Let the exception go to the upper layer.

If you just have try finally block, and without any catch block, people tend to ask, why are you not catching any exception in the try finally block. Ask the above questions, and see whether you really need to catch an exception or not. If you are just catching the exception and rethrowing it, it is of no use.

If you are developing UI

Are you handling all the exceptions? It is not the case that, you should have catch(Exception) in all the UI pages. If something unexpected happens, is there anyway of knowing what is the exact error and stacktrace. It does not matter, whether you display the error in the page itself, or in a log file or event viewer. If you don't have any way of knowing, how would you debug it? You may not always have access to the production machine, and you may not be able to attach a debugger in all the cases.