Give (an) example(s) of something bad that happens with a 'catch(Exception)' clause

Question

This is a follow up question to this one.

It seems to be generally accepted that doing a broad 'catch (Exception)' is a bad idea.

The reasoning is typically something like 'you must handle the exception properly' and 'catch what you can handle' and a few other generic sounding arguments.

Those generic answer sound reasonable, but they don't really satisfy me.

Let me be concrete. Here's a typical bit of code which is supposed to be 'bad'.

try {
   ... do something...
} catch (Exception e) {
   log(e); //leave a trace for debugging
   return ...a value the context can deal with...
}

A sceptical mind can remain unconvinced that not handling the exception, (which will probably blow up the entire program), is necessarily a better outcome than handling it in this generic way.

So I would really like some specific and convincing example(s), with code snippet(s), of something bad that actually happens because of a supposedly too broad catch clause like the one above.

PS: one could think about this question in other languages than Java, but since I want specific examples, this is really about specific Exceptions that might be raised by a Java program and JRE.

PS2: I am specifically interested in examples of Exception that are in fact a subtype of java.lang.Exception and not the more broadly 'Throwable'. So that rules out stuff like 'OutOfMemoryError' as valid examples.

Answer 1

Catching a NullPointerException can result in the application stumbling onward oblivious to the fact that something it needed was not done. Later the application will fail again or behave abnormally because that previous operation did not complete, but it will be harder to figure out now.

Eating an exception within a transaction can result in the transaction not getting rolled back when it should have been. You could end up with inconsistent data.

Eating interruptedException:

public void run() {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            doSomeWork();
            Thread.sleep();
        } catch (Exception e) {
        }
    }
}

If the thread gets interrupted while sleeping, the interrupted flag will get reset when the sleep method throws InterruptedException, since the catch doesn't restore the interrupt flag the while loop condition stays false and the thread doesn't exit.

Similarly, since InterruptedIOException is a subclass of IOException: if you have network IO code that only handles IOException then you can fail to restore the interrupt flag on and fail to detect that your thread has been interrupted.

Answer 2

The reason is you may want to handle different exceptions differently.

For example, in some applications I write I need to inform the user exactly what has gone wrong. If I just catch Exception I need to perform extra checks to distinguish between exceptions. If I catch specific exceptions I can easily do different things.

If I'm calling listFiles on a File, I might want to show a popup if a SecurityException occurs, but if a FileNotFoundException occurs I may want to open a FileChooser dialog.

EDIT: Now that I'm on a keyboard, I should also add that at times catch (Exception e) is good for the purposes of logging, but if you don't plan on handling it then you should always rethrow that exception. One man's trash is another's treasure as they say.

Answer 3

I'll turn that around and say that I think about the only time that an overly broad catch is appropriate is if the situation is "no matter what fails here, we're just quitting", like:

try {
   /* ... do something terribly important... */
} catch (Exception e) {
   System.err.println("We are totally screwed");
   e.printStackTrace();
   System.exit(1);
}