Effects of Try/Catch against Throwing Exceptions in a constructing class' constructor

Question

I was playing around with some of my code and came across something I didn't fully understand. I have a class called SentimentClassifier, the constructor of which looks like this:

public SentimentClassifier(final int nGramToBeUsed)  {
    try {
        classifier = (DynamicLMClassifier<?>) AbstractExternalizable.readObject(new File(etc));
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

I have another class which creates this one, like so:

public TwitterManager(final int nGramToBeUsed) {
    sentimentClassifier = new SentimentClassifier(nGramToBeUsed);
}

If I run the code like this, everything works fine. But if I change the first class from using try/catch to throw the exception, like so:

public SentimentClassifier(final int nGramToBeUsed) throws ClassNotFoundException, IOException  {
    classifier = (DynamicLMClassifier<?>) AbstractExternalizable.readObject(new File(etc));
}

Suddenly the second class complains that the IOException isn't being handled. Why is this thrown only for the thrown exception and not for the try/catch?

Answer 1

When you call a method M1 from another method M2:

• If some code in M1 raises some Checked Exception, and the method M1 itself handles it, rather than throwing it, you don't have to worry about the exception while calling it.

• Now, if the exception raised in M1, is not being handled in M1 itself, rather it is propagated up the stack trace, then M1 must declare that exception in the throws clause. This is just for the convenience of the calling method to know that it should be ready to handle those exception in case they are thrown. This is only the case with Checked Exception.

• But if the calling method M2, doesn't handle that exception, it has the option to re-declare that exception to be thrown in it's own throws clause, in which case the exception will be propagated further up the stack trace.

• If method M2 does neither of the previous two task, you will get a compiler error. Because you haven't given any proper path or way to handle the exception that can be thrown.

Note all the above arguments are true for Checked Exception only. For Unchecked exception, you don't need to handle it yourself, neither you need to declare it in throws clause.

---

Suggested Read:

• Java: checked vs unchecked exception explanation
• Unchecked Exception controversies
• JLS - The Kinds and Causes of Exceptions

Answer 2

If the constructor declares any exceptions, the calling code must handle them or declare them. After all, the constructor could throw/propagate these exceptions, and any code that calls it must handle them.

Answer 3

When you catch an exception, it means that you will deal with it on the catch block, and its consequences, so the external code can continue to progress without being warned about the internal exception.

If your exception is thrown, you are forcing by contract to any creator/invoker class to deal with any declared exception that could be produced during the initialization/execution process, as it can be critical for the business logic.

In this case, if the exceptions that can be generated during init are critical, and could stop the class from working properly, they should be thrown, as the creator class TwitterManager could have a disfuncional or partially initialized instance of the SentinelClassifier object, leading to unexpected errors.

Answer 4

In Java, if a method declares that throws an Exception (other than RuntimeException), callers must handle the exception. They can do this one of two ways: catch it, or declare that they themselves throw it.

You moved the handling of these two exceptions from the SentimentClassifier constructor to its callers.