10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors

In Java, exceptional conditions that disrupt the normal flow of program execution are represented as first-class objects. Robust exception handling requires a deep understanding of the object model rooted at java.lang.Throwable, the fundamental architectural boundary separating recoverable conditions from catastrophic system failures, and the compiler's strict reachability rules.

---

The Throwable Class Hierarchy

Every exception and error in Java is an instance of java.lang.Throwable or one of its direct or indirect subclasses. The hierarchy splits into two primary branches:

                         java.lang.Throwable
                                  |
                +-----------------+-----------------+
                |                                   |
         java.lang.Error                   java.lang.Exception
                |                                   |
     +----------+----------+             +----------+----------+
     |                     |             |                     |
OutOfMemoryError   StackOverflowError    |              RuntimeException
                                         |                     |
                                  (Checked Exceptions)  +------+------+
                                  e.g. IOException      |             |
                                  e.g. SQLException  NullPointer-  Arithmetic-
                                                     Exception     Exception

• java.lang.Throwable: The ultimate root of the exception hierarchy. Only instances of this class (or its subclasses) can be thrown by the Java Virtual Machine (JVM) or by the throw statement, and only these types can appear in a catch clause or throws declaration.
• java.lang.Error: Represents serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions that occur within the virtual machine itself or the underlying hardware.
• java.lang.Exception: Represents conditions that a reasonable application might want to catch and recover from.
• java.lang.RuntimeException: A special branch of Exception. Subclasses of RuntimeException (along with Error) are collectively termed unchecked exceptions. All other subclasses of Exception are termed checked exceptions.

---

The Error Category: Unrecoverable JVM Failures

Instances of java.lang.Error designate fatal infrastructure issues or system resource exhaustion. When an Error occurs, the integrity of the JVM or the operating environment is typically compromised.

Key examples to recognize:

• OutOfMemoryError: Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
• StackOverflowError: Thrown when a thread stack overflows, most frequently due to infinite recursion or excessively deep call stacks.
• NoClassDefFoundError: Thrown when the JVM or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or creation of a new instance) and no definition of the class could be found at runtime, even though it compiled cleanly.
• ExceptionInInitializerError: Signals that an unexpected exception occurred in a static initializer block or during the evaluation of a static field initializer.
• AssertionError: Thrown to indicate that an assert statement has failed.
• VirtualMachineError: The abstract superclass of OutOfMemoryError and StackOverflowError.

---

Checked vs. Unchecked Exceptions

The distinction between checked and unchecked exceptions is enforced entirely by the Java compiler.

The Catch-or-Declare Rule

Java enforces the catch-or-declare contract for all checked exceptions:

1. Catch: Enclose the code that may throw the exception in a try block with an associated catch block that handles the exception type (or a supertype).
2. Declare: Append a throws clause to the enclosing method or constructor signature declaring that the method may propagate the exception to its caller.

If a method contains an invocation of code that throws a checked exception without either catching it or declaring it in its throws clause, the Java compiler refuses to compile the code.

import java.io.*;

public class CatchOrDeclareDemo {
    // Approach 1: Declare via throws clause
    public void readFile(String path) throws IOException {
        FileReader reader = new FileReader(path); // FileReader throws FileNotFoundException (checked)
        reader.read();                            // read() throws IOException (checked)
        reader.close();
    }

    // Approach 2: Catch within try-catch block
    public void safeReadFile(String path) {
        try {
            FileReader reader = new FileReader(path);
            reader.read();
            reader.close();
        } catch (IOException e) {
            System.err.println("Failed to read file: " + e.getMessage());
        }
    }
}

Unchecked Exceptions (RuntimeException)

Unchecked exceptions are subclasses of java.lang.RuntimeException. They represent flaws in program logic, illegal arguments, or violated object states that can theoretically occur anywhere in an application.

Because runtime errors can happen in virtually any statement (such as dereferencing a reference or dividing numbers), forcing developers to declare them everywhere would clutter code with boilerplate. Therefore, unchecked exceptions are exempt from the catch-or-declare rule.

---

Common Built-in Exceptions for 1Z0-829

Exam questions frequently require identifying whether a specific exception is checked or unchecked, and what runtime scenario causes it to be thrown.

Unchecked Runtime Exceptions (java.lang)

Checked Exceptions

---

Compiler Reachability and Catch Block Validity

One of the trickiest areas on the 1Z0-829 exam involves compiler reachability checks on catch blocks. The Java compiler verifies whether a try block could ever possibly throw the checked exception listed in a catch clause:

1. Unreachable Checked Exception Catch Error: If a catch block catches a checked exception $E$, and the statements within the corresponding try block cannot possibly throw $E$ (or any subclass of $E$), the compiler rejects the code with an error: exception E is never thrown in body of corresponding try statement.
2. The Unchecked and Broad Catch Exemption: This reachability check does not apply to unchecked exceptions (RuntimeException or any of its subclasses) or to broad catch types (Exception and Throwable). You can catch NullPointerException, RuntimeException, Exception, or Throwable around any arbitrary code, even an empty try block!

import java.io.IOException;

public class ReachabilityRules {
    public void testReachability() {
        try {
            System.out.println("Processing...");
        } catch (RuntimeException e) {
            // COMPILES: Unchecked exceptions are always permitted in catch blocks
        } catch (Exception e) {
            // COMPILES: Exception is broad and could represent runtime exceptions
        }

        try {
            System.out.println("Testing checked...");
            // catch (IOException e) {} // COMPILE ERROR: IOException is never thrown in try block!
        } catch (Exception e) {
            // Valid
        }
    }
}

---

Java Assertions: Invariant Verification (Background)

Assertions, introduced via the assert keyword, enable developers to test internal assumptions and invariants during development and testing without incurring performance overhead in production.

Assertion Syntax

Java provides two forms of the assert statement:

1. Simple assertion:

   assert booleanExpression;
   

2. Assertion with detail expression:

   assert booleanExpression : detailExpression;
   

If assertions are enabled and booleanExpression evaluates to false, the JVM throws an AssertionError. In the two-argument form, detailExpression is evaluated and converted to a String to serve as the detail message of the AssertionError.

Controlling Assertions via the Command Line

By default, assertions are disabled at runtime. They must be explicitly activated using CLI flags:

• -ea or -enableassertions: Enables assertions for all system-loaded application classes.
• -da or -disableassertions: Disables assertions.
• Granular control:
  • -ea:com.order...: Enables assertions for package com.order and all its subpackages (the trailing ... denotes subpackages).
  • -da:com.order.Pricing: Disables assertions for the specific class Pricing within com.order.
  • More specific rules take precedence over broader rules.

# Enable in all packages except com.example.cache
java -ea -da:com.example.cache... com.example.MainApp