Java Exceptions

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Main.average(Main.java:9)
	at Main.main(Main.java:4)

• The first line names the exception type, ArithmeticException, and its message, / by zero.
• The at lines show the chain of method calls, most recent first. The top one, Main.java:9, is where the problem happened; below it is who called that method.

Start at the top, open that line of code and ask what value could have caused the message. Most bugs are found in a minute this way.

try {
    int n = Integer.parseInt(text);
    System.out.println(100 / n);
} catch (NumberFormatException e) {
    System.out.println("Not a number: " + text);
} catch (ArithmeticException e) {
    System.out.println("Can't divide by zero");
} finally {
    System.out.println("Done");
}

• Code in try runs normally until an exception is thrown; Java then jumps to the first matching catch.
• Order catch blocks from most specific to most general, because the first match wins.
• One block can catch several types: catch (NumberFormatException | ArithmeticException e).
• finally runs whether or not an exception happened, even after a return, which makes it the place for clean-up.

Java has two families of exceptions:

To declare a checked exception instead of handling it, add throws to the method: void load(String path) throws IOException. The caller then has to deal with it. This forces every part of the program to think about failures such as missing files.

Use throw to signal a problem yourself, usually when a method receives an invalid argument:

if (amount <= 0) {
    throw new IllegalArgumentException("Amount must be positive");
}

For problems specific to your program, create your own exception class by extending Exception (checked) or RuntimeException (unchecked).

Resources such as files and network connections must be closed. try-with-resources closes them automatically, even if an exception is thrown:

try (BufferedReader reader = Files.newBufferedReader(Path.of("data.txt"))) {
    System.out.println(reader.readLine());
}

Low-level exceptions often make little sense to the code that called you. A NumberFormatException deep inside a settings loader means "the configuration is broken" to the rest of the program. Catch the low-level exception and throw a more meaningful one, passing the original as the cause:

try {
    timeout = Integer.parseInt(settings.get("timeout"));
} catch (NumberFormatException e) {
    throw new IllegalStateException("Bad config value for timeout", e);
}

The cause is kept, so the stack trace shows both: your message first, then a Caused by: java.lang.NumberFormatException section pointing at the real source. e.getCause() returns it in code. Never throw away the original exception when wrapping; it's the most useful clue you have.

Exceptions are for unusual situations, not ordinary decisions. Checking if (text.isBlank()) is clearer and faster than letting a parse fail and catching the result. Good rules of thumb:

• Validate inputs you can check cheaply, and throw IllegalArgumentException when a method receives a value it can't accept.
• Catch an exception only where you can do something useful: retry, use a default, or show a helpful message.
• Otherwise let it travel up to a place that can report it, such as main or a web framework's error handler.

The exception hierarchy and try-catch-finally lessons practise these decisions in more depth.