The Case Against Checked Exceptions

How do you judge whether to make an exception checked or unchecked?

The meaning of the quote is this: If the client code can not recover from the problem, it needs to let the exception propagate to higher layers. If you use checked exceptions for that, you need to declare the checked exception through all call layers without benefit.

To rephrase the quote: If the exception is expected to propagate through the layers, make it unchecked. Only make it checked if the caller can actually do something about it.

Why we need to handle or throw checked exceptions in Java?

Your conceptual problem here is that you are conflating what happens at compile time and what happens at runtime; i.e. when the program is compiled by the programmer and when it is run by the user.

At compile time the compiler analyses the program to determine what exceptions could be thrown. For example

public static void main(String[] args) {
    FileInputStream fis = new FileInputStream(args[0]);  // HERE
}

The FileInputStream(String) constructor is declared as throws IOException. (Look it up.) So the compiler knows that the statement at HERE could throw an IOException. And IOException is a checked exception. (Look it up.)

It doesn't know that it will. It cannot possibly know that it will ... because it doesn't know what args[0] will contain. That is only known at runtime; i.e. when the program is run and the user supplies some command line arguments.

Q: What does checked exception mean here?

Well it means the main method either has to be declared as (for example) throws IOException, or it must catch it in a try-catch statement.

Q: So why is is a checked exception?

Because it was declared that way!

Q: Why was it declared that way?

To force the programmer to do deal with the possibility that the file being opened does not exist, is not readable, and so on. When the program is (eventually) run.

The compiler is saying "do something about this thing that might happen ...".

---

Just to reiterate. The compiler cannot check that the file exists because it doesn't know what pathname the user is going to provide. And even if it did know, AND it checked¹ that the file existed at compile, it couldn't know if the file was going to still exist at runtime, possibly on a completely different machine on a different network ... many years in the future.

^{1 - This is hypothetical. It doesn't check. It would be pointless.}

Comparing checked and unchecked exceptions (Performance, Benchmarks) in Java

From the perfomance point of view, building stack trace for exception is anyway the longest operation when an exception is generated (details).

Checked and unchecked exceptions make difference only at compile time. 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.

There is even Lomboks "magical" @SneakyThrows annotation to overcome this compile-time check. On the JVM (class file) level, all exceptions, checked or not, can be thrown regardless of the throws clause of your methods, which is why this works.

---

Related Topics