CODEWITHSUNDEEP
javaexception
William_He
William_He

Reputation: 357

Handle exception or throw exception in Java

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?

Upvotes: 2

Views: 2134

Answers (6)

samitgaur
samitgaur

Reputation: 5661

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.

Upvotes: 0

user220878
user220878

Reputation:

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.

Upvotes: 0

Enno Shioji
Enno Shioji

Reputation: 26882

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

Upvotes: 0

Cambium
Cambium

Reputation: 19392

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)

Upvotes: 0

Pace
Pace

Reputation: 43817

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.

Upvotes: 1

TofuBeer
TofuBeer

Reputation: 61526

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).

Upvotes: 2

Related Questions