Understanding checked vs unchecked exceptions in Java

Many people say that checked exceptions (i.e. these that you should explicitly catch or rethrow) should not be used at all. They were eliminated in C# for example, and most languages don't have them. So you can always throw a subclass of RuntimeException (unchecked exception)

However, I think checked exceptions are useful - they are used when you want to force the user of your API to think how to handle the exceptional situation (if it is recoverable). It's just that checked exceptions are overused in the Java platform, which makes people hate them.

Here's my extended view on the topic.

As for the particular questions:

1. Is the NumberFormatException consider a checked exception?
   No. NumberFormatException is unchecked (= is subclass of RuntimeException). Why? I don't know. (but there should have been a method isValidInteger(..))

2. Is RuntimeException an unchecked exception?
   Yes, exactly.

3. What should I do here?
   It depends on where this code is and what you want to happen. If it is in the UI layer - catch it and show a warning; if it's in the service layer - don't catch it at all - let it bubble. Just don't swallow the exception. If an exception occurs in most of the cases you should choose one of these:

   • log it and return
   • rethrow it (declare it to be thrown by the method)
   • construct a new exception by passing the current one in constructor

4. Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I?
   It could've been. But nothing stops you from catching the unchecked exception as well

5. Why do people add class Exception in the throws clause?
   Most often because people are lazy to consider what to catch and what to rethrow. Throwing Exception is a bad practice and should be avoided.

Alas, there is no single rule to let you determine when to catch, when to rethrow, when to use checked and when to use unchecked exceptions. I agree this causes much confusion and a lot of bad code. The general principle is stated by Bloch (you quoted a part of it). And the general principle is to rethrow an exception to the layer where you can handle it.

Whether something is a "checked exception" has nothing to do with whether you catch it or what you do in the catch block. It's a property of exception classes. Anything that is a subclass of Exception except for RuntimeException and its subclasses is a checked exception.

The Java compiler forces you to either catch checked exceptions or declare them in the method signature. It was supposed to improve program safety, but the majority opinion seems to be that it's not worth the design problems it creates.

Why do they let the exception bubble up? Isnt handle error the sooner the better? Why bubble up?

Because that's the entire point of exceptions. Without this possibility, you would not need exceptions. They enable you to handle errors at a level you choose, rather than forcing you to deal with them in low-level methods where they originally occur.

1. Is the above considered to be a checked exception?NoThe fact that you are handling an exception does not make it a Checked Exception if it is a RuntimeException.

2. Is RuntimeException an unchecked exception?Yes

Checked Exceptions are subclasses of java.lang.ExceptionUnchecked Exceptions are subclasses of java.lang.RuntimeException

Calls throwing checked exceptions need to be enclosed in a try{} block or handled in a level above in the caller of the method. In that case the current method must declare that it throws said exceptions so that the callers can make appropriate arrangements to handle the exception.

Hope this helps.

Q: should I bubble up the exact exception or mask it using Exception?

A: Yes this is a very good question and important design consideration. The class Exception is a very general exception class and can be used to wrap internal low level exceptions. You would better create a custom exception and wrap inside it. But, and a big one - Never ever obscure in underlying original root cause. For ex, Don't ever do following -

try {     attemptLogin(userCredentials);} catch (SQLException sqle) {     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.}

Instead do following:

try {     attemptLogin(userCredentials);} catch (SQLException sqle) {     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.}

Eating away original root cause buries the actual cause beyond recovery is a nightmare for production support teams where all they are given access to is application logs and error messages.Although the latter is a better design but many people don't use it often because developers just fail to pass on the underlying message to caller. So make a firm note: Always pass on the actual exception back whether or not wrapped in any application specific exception.

On try-catching RuntimeExceptions

RuntimeExceptions as a general rule should not be try-catched. They generally signal a programming error and should be left alone. Instead the programmer should check the error condition before invoking some code which might result in a RuntimeException. For ex:

try {    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);} catch (NullPointerException npe) {   sendError("Sorry, your userObject was null. Please contact customer care.");}

This is a bad programming practice. Instead a null-check should have been done like -

if (userObject != null) {    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);} else {   sendError("Sorry, your userObject was null. Please contact customer care.");}

But there are times when such error checking is expensive such as number formatting, consider this -

try {    String userAge = (String)request.getParameter("age");    userObject.setAge(Integer.parseInt(strUserAge));} catch (NumberFormatException npe) {   sendError("Sorry, Age is supposed to be an Integer. Please try again.");}

Here pre-invocation error checking is not worth the effort because it essentially means to duplicate all the string-to-integer conversion code inside parseInt() method - and is error prone if implemented by a developer. So it is better to just do away with try-catch.

So NullPointerException and NumberFormatException are both RuntimeExceptions, catching a NullPointerException should replaced with a graceful null-check while I recommend catching a NumberFormatException explicitly to avoid possible introduction of error prone code.