Exception Handling in Java: Checked vs Unchecked and try-with-resources

Exception handling questions fill a large share of Java interviews, and the details (checked versus unchecked, what finally really does, try-with-resources) are where marks are won or lost.

The hierarchy

Throwable
 |-- Error                      serious JVM problems: OutOfMemoryError, StackOverflowError (do not catch these)
 |-- Exception
      |-- IOException, SQLException, ...         checked exceptions
      |-- RuntimeException                       unchecked exceptions
           |-- NullPointerException, IllegalArgumentException, ArrayIndexOutOfBoundsException, ...

Checked versus unchecked

Errors are also unchecked. Do not catch them: the JVM may be in no state to continue.

try, catch and finally

public class Handling {
    public static void main(String[] args) {
        try {
            Integer.parseInt("abc");
        } catch (NumberFormatException e) {                       // the most specific handler first
            System.out.println("Bad number: " + e.getMessage());  // Bad number: For input string: "abc"
        } catch (RuntimeException e) {                            // more general handlers later
            System.out.println("Unexpected");
        } finally {
            System.out.println("always runs");                    // always runs
        }

        try {
            Object text = "hi";
            Integer wrong = (Integer) text;
        } catch (ClassCastException | NullPointerException e) {   // multi-catch
            System.out.println("caught " + e.getClass().getSimpleName());   // caught ClassCastException
        }
    }
}

• The first matching catch runs, so put specific exceptions before general ones. The other order does not compile ("exception already caught").
• Multi-catch (A | B) handles unrelated exceptions the same way.
• throw throws an exception object. throws is part of a method signature and declares what it may throw.

Can finally fail to run? Can it change the result?

finally runs whether or not an exception was thrown, even after a return. It does not run if:

• the JVM exits first (System.exit(...)) or crashes, or the machine loses power,
• the thread is killed, or the try block never ends (an infinite loop or a deadlock).

A return inside finally overrides the earlier return value and even swallows an exception. Avoid it:

public class FinallyTricks {
    @SuppressWarnings("finally")
    static int test() {
        try {
            return 1;
        } finally {
            return 2;                    // overrides the return value above: do not do this
        }
    }

    public static void main(String[] args) {
        System.out.println(test());      // 2
    }
}

final, finally and finalize

try-with-resources

Any class that implements AutoCloseable can be declared in the try (...) header. Java closes it automatically, in reverse order of opening, whether the block finishes normally or throws:

The output shows the order: , , , , , then the catch block. The exception from the body is the one that propagates. Exceptions thrown while closing are attached to it as suppressed exceptions (), so nothing is lost. A plain / would let a failure in replace the original exception. See the try-with-resources snippet.

Custom exceptions and causes

Extend for a checked exception or for an unchecked one, and keep the original as the cause:

Good habits

• Never leave an empty block. Log it, handle it, or rethrow it.
• Catch specific exceptions, not or , unless you are at the top of a request or thread.
• Do not use exceptions for normal control flow.
• Prefer for files, streams, sockets and database connections.
• Throw early with a clear message: .

Practise

1. Change so it does not throw, and predict the output before you run it.
2. Write a method that reads a file and declares . Call it once with a / and once with .
3. Take the Collections, Generics and Exceptions quiz.