Introduction

In Java, the correct idiom for chained resources is usually to declare each AutoCloseable in the same try-with-resources header, from outermost dependency to innermost wrapper. Java then closes them automatically in reverse order, which matches how chained streams and readers should be unwound.

The Standard Pattern

For a file reader wrapped in a buffered reader, write:

1import java.io.BufferedReader;
2import java.io.FileReader;
3import java.io.IOException;
4
5public class Example {
6    public static void main(String[] args) throws IOException {
7        try (
8            FileReader fileReader = new FileReader("input.txt");
9            BufferedReader bufferedReader = new BufferedReader(fileReader)
10        ) {
11            String line;
12            while ((line = bufferedReader.readLine()) != null) {
13                System.out.println(line);
14            }
15        }
16    }
17}

This is the idiomatic form. Both resources are managed explicitly, and Java closes bufferedReader before fileReader.

Why Declare Both Resources

Some developers assume only the outer wrapper should appear in the resource list because closing the wrapper will close the underlying resource. That often works, but declaring all owned resources in the try header is clearer when construction is chained and each object is an actual resource in its own right.

It also makes the lifetime of each object explicit and avoids hidden assumptions about who closes what.

Reverse-Order Closing Is Important

Java closes resources in reverse declaration order. That matters for chains because the wrapper depends on the underlying resource still being valid during its own close logic.

So this order is correct:

1. construct FileReader
2. construct BufferedReader
3. close BufferedReader
4. close FileReader

That is exactly what try-with-resources gives you automatically.

Suppressed Exceptions

One major advantage of try-with-resources over manual finally blocks is how it handles exceptions from both the body and the close operations.

If the body throws and then closing also throws, the close exception becomes suppressed rather than replacing the primary failure.

1catch (IOException e) {
2    System.out.println("Primary: " + e.getMessage());
3    for (Throwable suppressed : e.getSuppressed()) {
4        System.out.println("Suppressed: " + suppressed.getMessage());
5    }
6}

That behavior makes debugging much better than the older manual cleanup style.

When One Resource Variable Is Enough

If you only need the outer object and the outer object fully owns the inner resource, you can sometimes write just the outer wrapper:

try (BufferedReader reader = new BufferedReader(new FileReader("input.txt"))) {
    System.out.println(reader.readLine());
}

This is compact and valid. The tradeoff is readability. For simple cases, it is fine. For longer chains or more complex setup, naming each resource explicitly is usually clearer.

A Good Rule of Thumb

Use one resource declaration when the chain is short and obvious. Use separate declarations when:

• the chain is long
• debugging or logging setup may need intermediate objects
• the code is easier to understand with named resources

The right idiom is the one that makes ownership and closure order obvious without unnecessary noise.

Common Pitfalls

The biggest mistake is falling back to manual nested try/finally blocks when try-with-resources already models the ownership correctly.

Another mistake is building the chain in a way that hides which constructor can fail. If setup is complicated, explicit resource variables are easier to reason about.

A third issue is ignoring suppressed exceptions. If cleanup itself can fail, those suppressed exceptions may contain the clue you need.

Summary

• Declare chained resources in the same try-with-resources header when practical.
• Put them in dependency order so Java closes them in reverse order automatically.
• For very short obvious chains, a single outer resource can still be acceptable.
• Try-with-resources preserves suppressed exceptions, which helps debugging.
• Prefer the form that makes ownership and closure order obvious to readers.