What Is try-with-resources?

Try-with-resources is a variant of the try statement that declares one or more resources and guarantees they are closed when the block ends — whether it ends normally, by returning, or by throwing. It is the only correct way to handle resource cleanup in modern Java.

Compare it with the manual pattern. The old way needs a finally block, a null check on the resource in case the construction itself threw, and careful ordering so that a failure while closing does not hide the original failure. Try-with-resources replaces all of that with a declaration in the resource specification.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.StringReader;

public class Main {
    public static void main(String[] args) throws IOException {
        // The reader is closed automatically when the block ends.
        try (BufferedReader reader = new BufferedReader(new StringReader("first\nsecond"))) {
            System.out.println("line 1: " + reader.readLine());
            System.out.println("line 2: " + reader.readLine());
        }
        System.out.println("the reader is closed now");
    }
}

The output shows the two lines read from the reader, and then the confirmation printed after the block — by which point the reader has already been closed, without a single explicit call.

Three advantages over the manual pattern are worth naming. The cleanup happens even if the body throws, which is the whole point. The resource is closed in reverse order of declaration, so nested resources unwind correctly. And if the body throws and close also throws, try-with-resources preserves both: the body's exception propagates and the close exception is attached to it as a suppressed exception, reachable through getSuppressed. The manual finally pattern loses one of them, which is why the compiler even warns about it.

The try-with-resources block is also the natural place to put a resource whose close is expensive, because the JVM closes it at the end of the block whether or not you leave early with a return.

Resources are closed in the reverse order of their declaration. That is the order you want: the last thing opened is the first thing closed, so nested resources unwind the same way they were built. If you open a database connection and then a statement on it, the statement closes first.

When close throws, the rule is that the primary exception wins. If the try body completed normally, the exception from close propagates as the method's failure. If the try body threw, that exception is the one that propagates, and the exception from close is attached to it as a suppressed exception. Nothing is lost, and the stack trace of the original failure stays intact at the top.

public class Main {
    public static void main(String[] args) {
        try (Tracked first = new Tracked("first");
             Tracked second = new Tracked("second")) {
            System.out.println("body: using " + first.name + " and " + second.name);
        }
        System.out.println("after the try block");
    }
}

class Tracked implements AutoCloseable {
    final String name;

    Tracked(String name) {
        this.name = name;
        System.out.println("opened: " + name);
    }

    @Override
    public void close() {
        System.out.println("closed: " + name);
    }
}

The output makes the ordering visible. Both resources are opened first, in declaration order. The body runs. Then the resources are closed in reverse order — second, then first — and only after that does the statement after the block run.

Two related details. If the creation of a resource fails partway through the declaration list, the resources already created are still closed, so you never leak a partially constructed set. And the compiler wraps the close calls so that a failure in one close does not prevent the remaining resources from being closed — each subsequent close is attempted, and any further failures are added as suppressed exceptions too.

The resource must implement java.lang.AutoCloseable, which declares a single method, close(). java.io.Closeable extends AutoCloseable and additionally declares IOException as the checked exception its close method may throw, so it is the right choice for I/O resources where closing can genuinely fail.

The compiler does the rest. It rewrites your try-with-resources block into a try-finally with nested close calls, in reverse order, and it adds the suppressed-exception handling so that a failure in close never hides the primary exception. Because close is invoked through the AutoCloseable interface, the resource variable is implicitly final, so you cannot reassign it inside the block.

Two restrictions follow from that rewriting. The resource must be declared in the resource specification itself — you cannot assign it earlier and then list the variable name, because the compiler needs to know the exact expression to close. And the type must be a subtype of AutoCloseable, which is why a plain object with a close method is not enough; the interface is what makes the intent explicit and lets the compiler check it.

The syntax was later widened so that you can reference an already-declared effectively final variable in the resource list, which is convenient when you have one resource and a long method body:

You can also write try (reader) where reader is an effectively final local variable, and multiple resources are separated by semicolons. A resource that is also an instance of a Throwable-suppressing type is handled by the same machinery, and a variable declared in the resource list is in scope inside the try body but not afterwards.