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

Oracle Java SE 17 Developer Certified Professional 1Z0-829

Track your progress as you read

Finished sections get a check mark.

1 Introduction: The 1Z0-829 Exam

About the Java SE 17 Developer (1Z0-829) Exam

2 Chapter 1: Java Fundamentals & Language Basics

1.1 Primitive Types, Literals, Wrapper Classes, and Type Promotion/Casting 1.2 Local Variable Type Inference (`var`) Rules and Scoping 1.3 Operators, Precedence, Evaluation Order, and Short-Circuit Evaluation 1.4 Text Blocks, String Immutability, and StringBuilder APIs

3 Chapter 2: Program Flow & Decision Constructs

2.1 Conditional Branching with if/else and the Ternary Operator 2.2 Switch Statements and Switch Expressions 2.3 Iteration Constructs, Loop Control, and Branching Labels

4 Chapter 3: Object-Oriented Design & Class Mechanics

3.1 Class Declarations, Field/Method Signatures, and Access Modifiers 3.2 Constructors, Overloading, Initialization Order, and Garbage Collection 3.3 Inheritance, Method Overriding, Polymorphism, and `super`/`this` 3.4 Abstract Classes, Static Members, and Object Methods (`equals`, `hashCode`, `toString`)

5 Chapter 4: Advanced OOP: Interfaces, Records & Sealed Types

4.1 Interface Architecture: Default, Static, and Private Methods 4.2 Enumerations: Constants, Constructors, Methods, and Custom Bodies 4.3 Records: Canonical/Compact Constructors, Components, and Immutability 4.4 Sealed Classes and Interfaces: `permits`, Hierarchy Constraints, and Modifiers

6 Chapter 5: Pattern Matching & Nested Types

5.1 Pattern Matching for `instanceof` and Flow Scoping Mechanics 5.2 Nested Types: Member Inner, Static Nested, Local, and Anonymous Classes 5.3 Defensive Programming, Immutability Patterns, and Validation

7 Chapter 6: Generics, Collections & Arrays

6.1 Generic Classes, Interfaces, Methods, and Type Erasure 6.2 Bounded Type Parameters and Wildcards (PECS Rule) 6.3 Collections Framework: List, Set, Queue, and Deque APIs 6.4 The Map Interface, Sorting, Comparable, and Comparator 6.5 Arrays: Declaration, Initialization, Multidimensional Arrays, and the Arrays Utility Class

8 Chapter 7: Functional Programming & Lambda Expressions

7.1 Functional Interfaces and Lambda Syntax Rules 7.2 Standard Functional Interfaces in `java.util.function` 7.3 Method References: Static, Bound, Unbound, and Constructor References

9 Chapter 8: The Stream API

8.1 Stream Lifecycle: Creation, Pipeline Architecture, and Lazy Evaluation 8.2 Intermediate Stream Operations: Filtering, Mapping, Sorting, and Slicing 8.3 Terminal Stream Operations: Reduction, Matching, Finding, and Collecting 8.4 Primitive Streams (`IntStream`, `LongStream`, `DoubleStream`) and Numeric Statistics

10 Chapter 9: Advanced Streams & Collectors

9.1 The Optional Class: Safe Null Handling, Transformation, and Chaining 9.2 The Collectors API: Downstream Reductions, Grouping, and Partitioning 9.3 Parallel Streams: Fork/Join Pool, Spliterators, and Concurrency Pitfalls

11 Chapter 10: Exception Handling

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors 10.2 Exception Constructs: `try-catch-finally`, Multi-Catch, and Rethrowing 10.3 Try-With-Resources, `AutoCloseable`, Suppressed Exceptions, and Custom Exceptions

12 Chapter 11: Date/Time API & Localization

11.1 Date and Time Core Types: `LocalDate`, `LocalTime`, `LocalDateTime` 11.2 Timestamps, Intervals, and Durations: `Instant`, `Period`, and `Duration` 11.3 Time Zones, Daylight Saving Time (DST) Offsets, and `ZonedDateTime` 11.4 Internationalization and Localization: `Locale`, `ResourceBundle`, and Formatters 11.5 Formatting and Parsing Messages, Numbers, Percentages, and Localized Dates

13 Chapter 12: Java Platform Module System (JPMS)

12.1 Module Architecture, `module-info.java`, and Module Paths 12.2 Module Directives: `requires`, `requires transitive`, `exports`, and Qualified Exports 12.3 Reflection, Deep Encapsulation, `opens`, and Open Modules 12.4 Services in JPMS (`uses`, `provides...with`), Migration Paths, and Tooling (`jlink`, `jdeps`) 12.5 Compiling and Packaging Code: Non-Modular JARs, Modular JARs, and Migration Strategies

14 Chapter 13: Concurrency & Multithreading

13.1 Thread Fundamentals, `Runnable`, `Callable`, and Thread Lifecycle 13.2 Memory Visibility, `volatile`, Intrinsic Locks, and Synchronization 13.3 The Concurrency Framework: `ExecutorService`, Thread Pools, and `Future` 13.4 Concurrent Collections, Atomic Variables, Explicit Locks, and `CompletableFuture`

15 Chapter 14: Java I/O and NIO.2

14.1 Classical I/O: Byte and Character Streams, Readers, Writers, and Buffering 14.2 Object Serialization, `Serializable`, `transient`, and `serialVersionUID` 14.3 NIO.2 Architecture: `Path`, `Paths`, and Basic `Files` Operations 14.4 Advanced NIO.2: Directory Walking, Streams (`Files.lines`, `walk`), and `WatchService`

16 Chapter 15: Accessing Databases with JDBC

15.1 JDBC Architecture, Drivers, `DriverManager`, and `DataSource` Connections 15.2 SQL Execution: `Statement`, `PreparedStatement`, and `CallableStatement` 15.3 `ResultSet` Navigation, Data Types, and Transaction Management (Commit, Rollback, Savepoints)

17 Chapter 16: Annotations & the Java Logging API

16.1 Standard Annotations: @Override, @FunctionalInterface, @Deprecated, @SuppressWarnings, and @SafeVarargs 16.2 Java Logging API Basics: Logger, Levels, Handlers, and Configuration

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

Key Takeaways Explain This Topic AI

Try-with-resources automates resource management, guaranteeing that any resource implementing java.lang.AutoCloseable or java.io.Closeable is automatically closed at block exit without requiring manual finally logic.

Multiple resources declared in the resource header are closed in reverse order of declaration (LIFO), and all resources are closed before any explicit catch or finally blocks attached to that try statement execute.

AutoCloseable.close() declares throws Exception, whereas Closeable.close() declares throws IOException; implementations are encouraged to be idempotent so multiple close() invocations cause no harmful side effects.

Java 9+ supports using preexisting final or effectively final resource variables directly inside the try-with-resources header without declaring new local variables.

If both the try block and automatic close() invocations throw exceptions, the exceptions from close() are suppressed and attached to the primary exception via addSuppressed(), retrievable using getSuppressed().

Last updated: October 2026

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

Header Parentheses : Resource declarations are enclosed within parentheses immediately following the try keyword: try (Resource r = new Resource()) { ... } .

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();
• }

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

• Feature java.lang.AutoCloseable java.io.Closeable
• Package java.lang (no import required) java.io (requires import)
• Introduced Java 7 Java 5 (retrofitted in Java 7 to extend AutoCloseable )
• close() Signature void close() throws Exception; void close() throws IOException;
• Exception Hierarchy Declares broad throws Exception Declares narrower throws IOException

Idempotence Contract Recommended, but not strictly mandated by specification Strictly required: calling close() multiple times must have no effect

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:

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.

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:

• r1 initialized: prints Init:1
• r2 initialized: prints Init:2
• Try body executes: prints Body

RuntimeException thrown: resources close in reverse order:

• r2.close() executes: prints Close:2
• r1.close() executes: prints Close:1
• Explicit catch block catches the exception: prints Catch
• Explicit finally block executes: prints Finally
• Final output: Init:1 Init:2 Body Close:2 Close:1 Catch Finally

Warning

Catch and Finally Blocks See Closed Resources Because resources are closed before explicit catch and finally blocks run, any attempt to access those resources inside a catch or finally block operates on an already-closed resource!

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:

Primary Exception : An exception thrown from the body of the try block is recognized as the primary exception .

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) .

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[] .

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.