Java Exceptions and Exception Handling - Quiz

An exception is an object of a subclass of Throwable that is created at the moment of a runtime failure: an integer division by zero, a method call on null, a missing file, a badly formatted number. The object stores the exception type, a message and the stack trace.

A compile error (a missing semicolon, incompatible types such as int x = "5";) is detected by the javac compiler, and the program simply never starts. Exceptions occur only while already compiled code is running, so try-catch cannot protect you from compilation errors.

The method in which the exception occurred stops executing. The JVM looks for a matching catch block first in the current method, then in its caller, and so on up the call stack. The first matching handler receives the exception object, and the program continues right after that try-catch statement.

try {
    subRoutine();                 // inside: int a = 10 / 0;
    System.out.println("This line will not run");
} catch (ArithmeticException e) {
    System.out.println("Caught: " + e.getMessage());
}
// Output: Caught: / by zero

Java has no resumption: execution never returns to the line where the failure happened, and the remaining lines of the try block and of all interrupted methods are skipped. If an operation must be retried, wrap the try in a loop.

If no method in the call stack has a matching catch block, the default handler takes over: it prints the stack trace and terminates the thread in which the exception occurred.

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at ExceptionExample1.subRoutine(ExceptionExample1.java:8)
    at ExceptionExample1.main(ExceptionExample1.java:3)

Read a stack trace from top to bottom: the first line shows the exception type and message, the second shows where it happened (method and line number), and the lines below show who called that method. The cause of a bug is usually found in the topmost at ... line that points to your own code.

All exceptions inherit from Throwable, which has two branches: Error and Exception. The RuntimeException subclass decides whether an exception is checked:

• Checked — Exception and its subclasses except RuntimeException (IOException, SQLException, ParseException). The compiler requires you to catch them in catch or declare them in throws, otherwise you get a compile-time error.
• Unchecked — RuntimeException and its subclasses (ArithmeticException, NullPointerException, NumberFormatException); they usually signal bugs in program logic, and handling them is optional.
• Error (OutOfMemoryError, StackOverflowError) — also unchecked; these are serious JVM-level failures that are usually not caught at all.

Both:

• The JVM throws an exception automatically when a language rule is broken: ArithmeticException (integer division by zero), ArrayIndexOutOfBoundsException, NullPointerException, ClassCastException — without a single line of code on your side.
• JDK libraries throw exceptions with the throw statement inside standard classes: Integer.parseInt("abc") → NumberFormatException, reading a missing file → NoSuchFileException or FileNotFoundException (subclasses of IOException).
• Your code throws an exception when data is invalid from the business logic point of view: throw new IllegalArgumentException("Age cannot be negative").

• Swallowing an exception — a catch that reports nothing: catch (NumberFormatException e) { return 0; }. For parseAge("abc") the method silently returns 0, and the program keeps working with wrong data. If a method cannot handle an error in a meaningful way, it should report it to the caller: throw new IllegalArgumentException("Invalid age: " + input, e);
• Losing the cause — a new exception thrown inside catch without passing e breaks the Caused by chain, and the original stack trace is lost.
• catch (Exception e) just in case — it catches expected failures and bugs like NullPointerException alike, although bugs are better seen and fixed. Catch the most specific type.
• Exceptions instead of checks — catching ArrayIndexOutOfBoundsException instead of checking i < array.length is slower and harder to read. Exceptions are for exceptional situations, not for regular branching.