checked vs unchecked exceptions

[Kendall Ponder]

I found a useful list of checked vs unchecked exceptions on another thread here. One of the comments pointed out that all RuntimeExceptions were unchecked which I thought would be helpful to remember which was which but IOException is a checked exception and it clearly only happens at run time. The compiler can't know the file doesn't exist until the program runs. Is there a way to reason which exceptions are checked or unchecked or do I just need to memorize the lists? Thanks!

[Jeanne Boyarsky]

All exceptions are thrown at the time of the programming running. The checked vs runtime differences is for whether the compiler requires you to declare/handle.

You need to memorize this. If you are taking the OCA 7/8, it is easier because you only have to know IOException* is a checked exception (and all others are unchecked unless the exam tells you otherwise.) The list you found was from the SCJP 5/6 which covered more topics and therefore more exceptions.

You also have to recognize if a custom exception is checked or unchecked. For example:

class MyChecked extends Exception {}
class MyUnchecked extends RuntimeException {}

* Technically you don't even need to memorize this one, but it is most likely to show up of all them.

[Roel De Nijs]

Kendall Ponder wrote:Is there a way to reason which exceptions are checked or unchecked or do I just need to memorize the lists?

There's not really a way to reason, but luckily the rule to remember for checked/unchecked exceptions is pretty straightforward and easy to remember: All exceptions are checked exceptions, except for those indicated by Error, RuntimeException, and their subclasses. That's simple, isn't it?

Not related to the exam, but more some "on the job" advice: exception handling in Java is a very powerful mechanism with a number of benefits/advantages. But if you don't use it wisely it can become a real problem and your code will be cluttered making it less readible, less maintainable and so on. This is a small part of one of Oracle's tutorials and in my opinion a must-read for a java developer. It provides a general rule when you should opt for a checked/unchecked exception (of course, every rule has its own... exceptions).

[Kendall Ponder]

Roel De Nijs wrote:

Kendall Ponder wrote:Is there a way to reason which exceptions are checked or unchecked or do I just need to memorize the lists?

There's not really a way to reason, but luckily the rule to remember for checked/unchecked exceptions is pretty straightforward and easy to remember: All exceptions are checked exceptions, except for those indicated by Error, RuntimeException, and their subclasses. That's simple, isn't it?

The rule is simple but I would need to know which exceptions were subclasses of RuntimeException and which were not and as far as I can tell the only way to do that is to memorize whether each exception is a subclass of RuntimeException. Maybe I am missing something but it isn't clear to me why IOException is not a RuntimeException and NullPointerException is. I assume NullPointerException is unchecked because the possibility of a NullPointerException is so prevalent. Thanks for the link to Oracle's tutorial.

[Paul Anilprem]

1. You need to memorize the common runtime exceptions - NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, ArithmeticException, IllegalStateException, and IllegalArgumentException. Not too many. Anything that ends with Error is also unchecked. You can safely assume that the rest (i.e. out of the ones required for the exam) are all checked exception.

2. In case you forget or are not sure about an exception, here is the trick to make an educated guess - programming errors are almost always reflected through runtime exceptions. For example, a well written program should never try to access an array beyond its length. If it does, you will get an ArrayIndexOutOfBoundsException, which, you guessed it, is a RuntimeException. Same applies to NPE, ClassCastException, and ArithmeticException.
A well written program should anticipate that file manipulation is beyond the program's control. It depends a lot on the environment (such as file being there, enough disk space, access rights etc.). Even if you write a perfectly valid program, you have to account for the possibility that a file is not available for reasons beyond your control. Therefore, IOException is a checked exception.

HTH,
Paul.

[Kendall Ponder]

Thanks for all of the help!

[Raghavan Muthu]

Kendall Ponder wrote:
I found a useful list of checked vs unchecked exceptions on another thread here. One of the comments pointed out that all RuntimeExceptions were unchecked which I thought would be helpful to remember which was which but IOException is a checked exception and it clearly only happens at run time. The compiler can't know the file doesn't exist until the program runs. Is there a way to reason which exceptions are checked or unchecked or do I just need to memorize the lists? Thanks!

It is a very good question. I appreciate your thinking here.

The fact why IOException has been classified as a Checked Exception is that the file may or may not really exist which can be determined ONLY at the runtime. However the Programmer/Developer is excepted to know that there is a potential risk (of the file not being present) and he should really be accounting that risk while coding and he should have handled a way to deal with the exception(al scenario). The reason is to have a graceful degradation of an application otherwise the application may be stuck abruptly.

Coming to your other dimension of why it is not a runtime exception is that the runtime exceptions are generally caused by the input fed by the user and he can very well take care of it. So it does not need to be taken care in a proactive fashion.

Hope this helps!!!

Cheers,
Raghavan alias Saravanan M.

[Stephen Paulsen]

Raghavan Muthu wrote:
The fact why IOException has been classified as a Checked Exception is that the file may or may not really exist which can be determined ONLY at the runtime. However the Programmer/Developer is excepted to know that there is a potential risk (of the file not being present) and he should really be accounting that risk while coding and he should have handled a way to deal with the exception(al scenario).

As Jeanne Boyarsky pointed out, all exceptions are determined ONLY at runtime. A NullPointerException certainly can only be determined at runtime, yet it is an unchecked exception.

The second part of your statement, "the Programmer/Developer is excepted[sic] to know" and should be accounting for it, is the real crux of the matter.
If the situation can be anticipated and the program has a reasonable chance to recover from it, it should be a checked exception. Unchecked exceptions are for things that can happen essentially anywhere, and there may be no way for your program to recover in a practical way.

Raghavan also wrote:
Coming to your other dimension of why it is not a runtime exception is that the runtime exceptions are generally caused by the input fed by the user and he can very well take care of it. So it does not need to be taken care in a proactive fashion.

Runtime exceptions are most often caused by programmer error, not user input. As a programmer, you should be validating the user input, not accepting it blindly. This is a case where you probably do want to catch runtime exceptions, such as [tt]catch (NumberFormatException e)[tt] when converting String user input into a numeric value.

Roel De Nijs link to Oracle's article Unchecked Exceptions — The Controversy makes all this clear.

[Guillermo Ishi]

Kendall Ponder wrote:
IOException is a checked exception and it clearly only happens at run time.

I think checked means checked by the compiler, in other words the compiler forces you to handle a possible exception. For example you can't read a file unless you set up a try/catch to handle the (checked) IOException it might throw.

[Roel De Nijs]

Guillermo Ishi wrote:I think checked means checked by the compiler

Spot-on! Checked exceptions are subject to the Catch or Specify Requirement (also known as the handle or declare requirement) and that's checked/verified by the compiler. If your code doesn't meet this requirement, you'll get a compiler error. Unchecked exceptions (errors and runtime exceptions) are not subject to the Catch or Specify Requirement.

[Roel De Nijs]

Kendall Ponder wrote:The rule is simple but I would need to know which exceptions were subclasses of RuntimeException and which were not and as far as I can tell the only way to do that is to memorize whether each exception is a subclass of RuntimeException.

Maybe it could be helpful to create a method throwing one of the exceptions you need to memorize. If the method compiles, it's an unchecked exception. If the method doesn't compile, it's a checked exception (because the compiler forces you to handle or declare a checked exception). An example:

void methodA() { throw new NullPointerException(); }
void methodB() { throw new IOException(); }

methodA compiles => NullPointerException is an unchecked exception. methodB does not compile => IOException is a checked exception.

And of course when you use these exceptions more often, you'll automatically know if it's a checked or an unchecked one. Practice makes perfect!

Kendall Ponder wrote:Maybe I am missing something but it isn't clear to me why IOException is not a RuntimeException and NullPointerException is. I assume NullPointerException is unchecked because the possibility of a NullPointerException is so prevalent.

No, that's not the reason. If you are working with reading and writing of files, the IOException is maybe even more prevalent than the NullPointerException. Let's have a closer look at the exceptions to (hopefully) get a better understanding.

In Java you have 3 kinds of exceptions:

checked exception: an exceptional condition that a well-written application should anticipate and recover from (e.g. the file entered by the user doesn't exist and a FileNotFoundException is thrown)

error: an exceptional condition that is external to the application, and that the application usually cannot anticipate or recover from (e.g. out of memory)

runtime exception: an exceptional condition that is internal to the application, and that the application usually cannot anticipate or recover from (e.g. invoking a method on a null reference)

Errors and runtime exceptions are collectively known as unchecked exceptions.

A runtime exception (e.g. NullPointerException or ArrayIndexOutOfBoundsException) usually indicate a programming bug. And it's a (very) bad practice to catch these runtime exceptions! Instead of catching a runtime exception, you should fix the programming bug. For example:

Map<String, Person> persons = new HashMap<>();
Person joe = persons.get("joe");
// BAD
try {
    System.out.println(joe.toString());
} catch (NullPointerException e) {
    System.out.println("person joe unknown");
}
// GOOD
System.out.println(joe == null ? "person joe unknown" : joe.toString());

Both BAD and GOOD will have the same output. But the GOOD solution is much better than the BAD one (hence their names ). Simply because in the GOOD solution the programming bug was fixed and in the BAD one the bug is still there (but it's hidden by the use of an exception handler).

I hope you know have a better understanding why some exceptions are checked and others are unchecked!
Kind regards,
Roel