10.3 Try-With-Resources, `AutoCloseable`, Suppressed Exceptions, and Custom Exceptions

10.3 Try-With-Resources, AutoCloseable, Suppressed Exceptions, and Custom Exceptions

Modern Java applications manage external system resources—such as file handles, database connections, sockets, and streams—using the try-with-resources statement. Introduced in Java 7 and refined in Java 9, try-with-resources prevents resource leaks, provides deterministic closing semantics, manages suppressed exceptions, and simplifies clean object-oriented architecture.

---

Automatic Resource Management with Try-With-Resources

In classical Java code, releasing resources in finally blocks required nested try-catch structures and defensive null-checking:

// CLASSICAL ANTI-PATTERN (PRE-JAVA 7): Verbose and prone to resource masking
FileInputStream fis = null;
try {
    fis = new FileInputStream("app.log");
    fis.read();
} catch (IOException e) {
    // Handle read error
} finally {
    if (fis != null) {
        try {
            fis.close();
        } catch (IOException e) { /* close exception masks read exception! */ }
    }
}

The try-with-resources statement replaces this cumbersome pattern with automatic, compiler-generated cleanup. Any object whose type implements java.lang.AutoCloseable can be instantiated or referenced within the try specification header:

try (FileInputStream fis = new FileInputStream("app.log")) {
    int data = fis.read();
} catch (IOException e) {
    System.err.println("I/O failed: " + e.getMessage());
}

Try-With-Resources Syntax Rules

1. Header Parentheses: Resource declarations are enclosed within parentheses immediately following the try keyword: try (Resource r = new Resource()) { ... }.
2. Optional Catch and Finally: Unlike a standard try block, a try-with-resources statement does not require an explicit catch or finally block. A try-with-resources block with neither catch nor finally is completely valid:

   // Valid: Automatically closes resource without explicit catch or finally
   try (var fis = new FileInputStream("data.bin")) {
       fis.read();
   }
   

3. Multiple Resources: Multiple resources are separated by semicolons (;). The trailing semicolon after the final resource is optional:

   try (Reader in = new FileReader("in.txt");
        Writer out = new FileWriter("out.txt")) {
       out.write(in.read());
   }
   

---

AutoCloseable vs. Closeable Interfaces

The try-with-resources mechanism is powered by two foundational interfaces in the Java platform:

              java.lang.AutoCloseable (Java 7)
               void close() throws Exception;
                            ^
                            | extends
              java.io.Closeable (Java 5)
              void close() throws IOException;

Key Differences Between Interfaces

Overriding close() Without Checked Exceptions

Because Java permits overriding methods to declare fewer or narrower checked exceptions, an AutoCloseable implementation can declare that its close() method throws a specific subclass (e.g. IOException), an unchecked exception, or no exception at all:

public class MemoryBuffer implements AutoCloseable {
    @Override
    public void close() {
        // No throws clause!
        System.out.println("Buffer cleared");
    }
}

When using MemoryBuffer in a try-with-resources statement, the compiler does not require catching or declaring Exception, because the concrete close() method throws no checked exceptions!

---

Resource Closing Order and Execution Order with Catch/Finally

Exam questions frequently test the exact sequence in which resources are closed and when associated catch and finally blocks execute.

Two inviolable rules govern this lifecycle:

1. Reverse Declaration Order (LIFO): Resources declared in the try header are closed in the exact opposite order of their declaration. The resource created last is closed first.
2. Resources Close BEFORE Catch and Finally: Automatic calls to close() occur immediately upon exiting the protected try block body, BEFORE any explicit catch or finally blocks associated with the try statement execute!

class Res implements AutoCloseable {
    private final String id;
    public Res(String id) { this.id = id; System.out.print("Init:" + id + " "); }
    public void close() { System.out.print("Close:" + id + " "); }
}

public class LifecycleTrace {
    public static void main(String[] args) {
        try (Res r1 = new Res("1"); Res r2 = new Res("2")) {
            System.out.print("Body ");
            throw new RuntimeException("Error");
        } catch (Exception e) {
            System.out.print("Catch ");
        } finally {
            System.out.print("Finally");
        }
    }
}

Step-by-step execution trace:

1. r1 initialized: prints Init:1
2. r2 initialized: prints Init:2
3. Try body executes: prints Body
4. RuntimeException thrown: resources close in reverse order:
   • r2.close() executes: prints Close:2
   • r1.close() executes: prints Close:1
5. Explicit catch block catches the exception: prints Catch
6. Explicit finally block executes: prints Finally

Final output:

Init:1 Init:2 Body Close:2 Close:1 Catch Finally

---

Java 9+ Effectively Final Resource References

In Java 7 and 8, every resource managed by a try-with-resources statement had to be declared as a new variable inside the try parentheses. Java 9 introduced the ability to use pre-existing variable references, provided they are either explicitly declared final or are effectively final:

public void process(BufferedReader reader) throws IOException {
    // Java 9+ syntax: pass preexisting variable directly into try header
    try (reader) {
        System.out.println(reader.readLine());
    }
    // reader is closed here
}

The Effectively Final Constraint

A variable is effectively final if its reference is never modified after assignment. If the code reassigns the variable anywhere in the method, the compiler rejects the try-with-resources statement:

BufferedReader r1 = new BufferedReader(new FileReader("a.txt"));
// try (r1) { /* ... */ } // COMPILE ERROR if r1 is reassigned anywhere below!
r1 = new BufferedReader(new FileReader("b.txt")); // Reassignment breaks effectively final status

---

Suppressed Exceptions Architecture

In classical exception handling, if both the try block and the finally block threw exceptions, the exception thrown in finally completely masked and destroyed the original exception.

Try-with-resources solves this via the suppressed exceptions mechanism:

1. Primary Exception: An exception thrown from the body of the try block is recognized as the primary exception.
2. Suppression During Close: If one or more resources throw exceptions while being automatically closed, those secondary exceptions do not mask the primary exception. Instead, the runtime catches each closing exception and attaches it to the primary exception using Throwable.addSuppressed(Throwable exception).
3. Retrieval: The caller or catching block receives the primary exception. The attached suppressed exceptions can be inspected by invoking Throwable.getSuppressed(), which returns an array of Throwable[].
4. Normal Completion with Failing Close: If the try body completes normally without throwing an exception, but a resource's close() method throws an exception, that close() exception becomes the primary exception thrown to the caller.

class Faulty implements AutoCloseable {
    private final String id;
    public Faulty(String id) { this.id = id; }
    public void close() throws Exception {
        throw new Exception("Close failed for " + id);
    }
}

public class SuppressedDemo {
    public static void main(String[] args) {
        try (Faulty f1 = new Faulty("F1"); Faulty f2 = new Faulty("F2")) {
            throw new IllegalStateException("Primary computation failed");
        } catch (Exception e) {
            System.out.println("Caught: " + e.getMessage());
            for (Throwable s : e.getSuppressed()) {
                System.out.println("  Suppressed: " + s.getMessage());
            }
        }
    }
}

Output:

Caught: Primary computation failed
  Suppressed: Close failed for F2
  Suppressed: Close failed for F1

Notice that the suppressed exceptions appear in the reverse closing order (F2, then F1).

---

Designing Custom Exceptions

When building enterprise applications, developers define domain-specific exceptions to communicate business rule violations.

Checked vs. Unchecked Custom Exceptions

• Extend java.lang.Exception: To create a checked exception for recoverable business scenarios where callers must provide an alternative fallback.
• Extend java.lang.RuntimeException: To create an unchecked exception for unrecoverable state violations, precondition breaches, or programming errors.

The Four Standard Constructor Idioms

When creating custom exceptions, follow the standard library pattern by implementing the four canonical constructors from Throwable:

public class PaymentProcessingException extends Exception {
    // 1. Default no-arg constructor
    public PaymentProcessingException() {
        super();
    }

    // 2. Message-only constructor
    public PaymentProcessingException(String message) {
        super(message);
    }

    // 3. Cause-only constructor (exception chaining)
    public PaymentProcessingException(Throwable cause) {
        super(cause);
    }

    // 4. Message and cause constructor
    public PaymentProcessingException(String message, Throwable cause) {
        super(message, cause);
    }
}

Passing the cause parameter to super(cause) preserves the original root exception (accessible via getCause()), ensuring full stack trace traceability across architectural layers.