In Java, what is the difference between catch a generic exception and a specific exception (eg. IOException?)

Question

Currently I'm catching only generic exceptions, but i want change this to catch the specific exceptions, but what is the advantage of this?

Answer 1

The difference between performing a general try/catch statement and catching a specific exception (e.g. a FileNotFoundException) typically depend on what errors you need to handle and what errors you don't need to worry about. For instance:

catch (Exception e) {    //A (too) general exception handler
...
}

The code above will catch EVERY exception that is thrown inside of the try statement. But maybe you don't want to handle every error. What can you do with an "OutOfMemory" exception?

A better method of error handling would be to perform some default action if the error is unknown or something you can't do anything about, and perform another action if you discover that you can do "Plan B" if you catch.

For example, assume you are trying to open a file, but the file doesn't exist. You can catch the FileNotFoundException and create a new blank file as below:

catch (FileNotFoundException e) {    //A specific exception handler
    //create a new file and proceed, instead of throwing the error to the user
}catch (Exception e) {    //For all other errors, alert the user
    ...
}

This has been the most effective and user-friendly method of error checking that I've used in the past.

Answer 2

Catching specific exceptions allows you to tailor specific responses to each case.

At a logical level, a series of catch blocks is the same as having one catch block, and then writing your own conditional logic inside the single catch block. Note that the conditional logic would also have to cast the exception as specific subtypes if you want access to detailed information declared within the subtype.

The few disadvantages of catching each exception separately include the whole try - catch structure growing very large and making the logic of the containing method harder follow, and having to repeat code in many or all of the separate catch blocks (for example, logging the exception).

In certain cases, the complexity of some underlying API warrants both the handling of all the different exceptions and the extraction of the try-catch structure into a utility method. For example, method invocation through reflection seems to regularly warrant having facade APIs.

At an API design level, there is always a balancing act between

• A very rich (public) exception hierarchy
• Incorporating error codes as part of the information contained in some base exception, and
• A public set of marker interfaces and using private exception subtypes