views:

102

answers:

6

Like such Java code snippet:

public void func() throws XXXException {    // throw exception to outer body ------ (2)
    try {
        ......
    } catch(XXXException ex) {
        // handle exception ------ (1)
    }
}

In this condition, how you decide to choose (1) or (2)? Is there any principles in Java exception handling?

+2  A: 

If the code that calls the method that throws the exception can properly deal with the exception then it should catch it. If it cannot deal with the exception then it should throw it up.

For instance, if "func" is low-level networking code it should probably throws the exception rather than catch it. The code that ultimatly catches it should display an error message to the user (or whatever else makes sense). If instead "func" is part of the GUI layer it probably would catch the exception and display an error message to the user (or whatever else makes sense).

TofuBeer
+1  A: 

If you can handle it you handle it. For example, if you are loading a properties file and you get a FileNotFoundException perhaps you can use some default properties. In this case you handle the exception.

If you can't handle it but you think someone else might be able to down the road then you should throw the exception. For example, perhaps you are writing a general utility for reading in property files. In this case you might rethrow the exception so that whoever is using your general utility can then go ahead and load defaults.

If you can't handle it and you don't want to introduce the complexity of throwing the exception then you should send the exception to an exception handling service that you can configure at runtime. This way when unit testing the exception handling service can take that exception and rethrow it as a runtime exception which will crash the test immediately. However, in production code the exception handling service might just log the exception and try and restart the program somehow.

Pace
A: 

You choose (1) if you want to do something about the exception (e.g. log it, extract info from it). It's also common to throw the exception in the catch block after you are done with it (i.e. throw ex;)

You choose (2) if you want the users of your method to handle it (e.g. Java's String.matches method)

Cambium
A: 

In a nut shell, choose to throw exception to outer body, unless you have a specific reason to catch the exception.

Enno Shioji
A: 

There's an excellent article at the O'Reilly java site about this topic. It goes into some detail about when you should catch versus throw, as well as other stuff, like checked versus unchecked exceptions.

anjruu
A: 

Exceptions represent error conditions. When an error condition occurs, some method in the call chain knows how to handle that error in the context of the application i.e. what to do - ignore, retry, abort, etc. If this is that method that knows how to handle this exception, then you handle it here. If not, you throw it so that the method one level up the call chain receives it and acts on it.

Sometimes, you may want to do both (1) and (2). You may handle the exception, do some intermediate processing and then rethrow it.

public void func() throws XXXException {
    try {
        ......
    } catch(XXXException ex) {
        logger.log(ex);
        throw ex;
    }
}

Or you may catch one exception and throw another, for example when you want to wrap a third party exception into an application exception.

public void func() throws YYYException {
    try {
        ......
    } catch(XXXException ex) {
        throw new YYYException(ex);
    }
}

In both cases, this is not the method that fully handles the exception and only does some processing along the way as the exception percolates to the top.

Samit G.
Log rethrow is almost never a good idea. It leads to cluttered logs with duplicated stack traces. I'm not sure what other intermediate processing there is besides cleanup (should be in finally) and handling the exception (shouldn't have a rethrow).
ILMTitan
I agree. I used it to demonstrate the catch-rethrow case. May be chose a bad example. If one ever requires to do this, what will need to be done inside the catch will be guided by application requirements. For instance, you may need to roll something back and throw the exception back to give the caller a chance to react.
Samit G.