Java try-with-resources

try-with-resources is the compiler-managed solution to the problem of reliably closing resources after use. Declare a resource in the parentheses after try, use it in the block, and the compiler generates the close call automatically — whether the block completes normally, throws an exception, or hits a return. The two failure modes of manual try-finally resource management — forgetting to close and silently swallowing the original exception when close() itself throws — are both handled correctly by try-with-resources.

What Is try-with-resources?

Introduced in Java 7, try-with-resources is a try block with a resource declaration list in parentheses. Any object declared there must implement java.lang.AutoCloseable. The compiler generates code that calls close() on each declared resource when the try block exits, in reverse order of declaration, regardless of how the block exits.

SYNTAX:
  try (ResourceType resource = new ResourceType(...)) {
      // use resource
  }
  // resource.close() called automatically here

MULTIPLE RESOURCES:
  try (ResourceType1 r1 = new ResourceType1();
       ResourceType2 r2 = new ResourceType2()) {
      // use r1 and r2
  }
  // r2.close() called first, then r1.close() — REVERSE order of declaration

COMBINED WITH catch AND finally:
  try (Connection conn = dataSource.getConnection()) {
      Statement stmt = conn.createStatement();
      return stmt.executeQuery(sql);
  } catch (SQLException sqlException) {
      throw new DataAccessException("Query failed", sqlException);
  } finally {
      metrics.recordQueryAttempt(); // always runs — even after auto-close
  }
  // conn.close() is called BEFORE catch and finally run

JAVA 9 ENHANCEMENT — effectively final variable:
  Connection conn = dataSource.getConnection();
  // conn must be effectively final (never reassigned after this line)
  try (conn) { // no re-declaration needed
      return conn.createStatement().executeQuery(sql);
  }
  // conn.close() called automatically

Basic Overview — Why try-with-resources Exists

THE TWO PROBLEMS WITH MANUAL try-finally:

PROBLEM 1 — Forgotten close():
  Connection conn = dataSource.getConnection();
  try {
      return conn.createStatement().executeQuery(sql);
  } finally {
      // Developer forgot conn.close() — connection leaks every call
      // After enough calls: "Too many connections" error in production
  }

PROBLEM 2 — Exception suppression in finally:
  Connection conn = dataSource.getConnection();
  try {
      conn.executeQuery(sql);       // throws SQLException("Query failed")
  } finally {
      conn.close();                 // ALSO throws IOException("Socket error")
      // IOException from close() REPLACES the original SQLException
      // Caller receives "Socket error" — the real cause "Query failed" is LOST
  }

HOW try-with-resources SOLVES BOTH:

  SOLUTION TO PROBLEM 1:
  Compiler generates the close() call — you cannot forget it
  Even if a developer never writes conn.close(), the bytecode has it

  SOLUTION TO PROBLEM 2:
  If try body throws AND close() throws, try-with-resources:
    — Keeps the original exception as the primary exception
    — Attaches the close() exception as a SUPPRESSED exception
    — Callers retrieve it with: primaryException.getSuppressed()
  The original failure is never lost

AUTOCLOSEABLE CONTRACT:
  public interface AutoCloseable {
      void close() throws Exception;
  }
  Any class implementing this can be used in try-with-resources.
  Closeable extends AutoCloseable (close() throws IOException specifically).
  All JDK I/O classes, JDBC types, and many libraries implement one of these.

How try-with-resources Works Internally

The Java compiler transforms a try-with-resources block into an equivalent try-finally structure — but one that handles exception suppression correctly.

COMPILER TRANSFORMATION (Java 7+):

  SOURCE (simple form):
    try (Connection conn = dataSource.getConnection()) {
        return conn.executeQuery(sql);
    }

  GENERATED BYTECODE (equivalent):
    Connection conn = dataSource.getConnection();
    Throwable primaryException = null;
    try {
        return conn.executeQuery(sql);
    } catch (Throwable tryException) {
        primaryException = tryException;
        throw tryException;
    } finally {
        if (conn != null) {
            if (primaryException != null) {
                try {
                    conn.close();
                } catch (Throwable closeException) {
                    // SUPPRESSION: close exception attached to primary — NOT replacing it
                    primaryException.addSuppressed(closeException);
                }
            } else {
                conn.close(); // no try exception — close exception propagates normally
            }
        }
    }

  KEY INSIGHT:
  The compiler generates the primaryException variable to track whether
  the try body threw. If it did, close() exceptions are suppressed onto it.
  If the try body succeeded, a close() exception propagates normally.
  This is the suppression handling that manual try-finally cannot do easily.

MULTIPLE RESOURCES — reverse close order:
  try (A a = new A(); B b = new B()) { ... }

  Generates:
    A a = new A();
    try {
        B b = new B();
        try { body } finally { b.close(); }  ← inner: B closed first
    } finally { a.close(); }                 ← outer: A closed after B
  The last declared resource is closed first — reverse order.

Core Operations with Examples

Single Resource — The Simplest Form

Output:
=== Single resource — read first line ===
  Read: Hello from Bengaluru
Result: Hello from Bengaluru

=== Resource closed even when exception occurs ===
  readLine() called — about to throw
  close() called automatically — resource cleaned up
Caught: Simulated read failure
Execution continues after try-with-resources

Multiple Resources — Reverse Close Order

Output:
--- Three resources: close order is REVERSE of declaration ---
  OPEN: Resource-1
  OPEN: Resource-2
  OPEN: Resource-3
  USE:  Resource-1
  USE:  Resource-2
  USE:  Resource-3
  Try block complete
  CLOSE: Resource-3
  CLOSE: Resource-2
  CLOSE: Resource-1

--- Try throws + close throws: suppression in action ---
  OPEN: FailCloseResource
  USE:  FailCloseResource
  CLOSE: FailCloseResource
Primary: PRIMARY exception from try body
Suppressed count: 1
  Suppressed: Close failed for: FailCloseResource

--- Multiple close failures: all attached as suppressed ---
  OPEN: FailResource-1
  OPEN: FailResource-2
  CLOSE: FailResource-2
  CLOSE: FailResource-1
Primary: PRIMARY exception from try body
Suppressed count: 2
  Suppressed: Close failed for: FailResource-2
  Suppressed: Close failed for: FailResource-1

Custom AutoCloseable Classes

Any class that implements AutoCloseable can be used in try-with-resources. This is the right pattern for any object that holds a resource that needs deterministic cleanup — not just JDK I/O types.

Output:
=== Custom pooled connection ===
  [POOL] Borrowed: conn-007
  result-of-[SELECT * FROM products LIMIT 5]-via-conn-007
  [POOL] Returned: conn-007

=== Timed operation ===
  [TIMER] Started: processPaymentBatch
  Processing complete
  [TIMER] Completed: processPaymentBatch in 6ms

=== Transaction scope — committed ===
  [TX] Begin: TX-8821
  Updating inventory...
  [TX] Committed: TX-8821

=== Transaction scope — rolled back on exception ===
  [TX] Begin: TX-8822
  Updating inventory...
  [TX] Rolled back: TX-8822
  Caught: Inventory DB unavailable

Real-World Example — Flipkart Order Export Service

An order export service at Flipkart reads orders from a database, processes them, and writes the results to a file. Three resources are involved: a database connection, a prepared statement, and a file writer. They are declared in try-with-resources, closed in reverse order automatically, and the original exception is preserved even if closing one of them also fails.

Output:
=== Export 4 delivered orders ===
  Exporting up to 4 delivered orders to /exports/delivered.csv
  [DB]   Connection opened to: jdbc:pg://orders-db.internal/orders
  [DB]   Statement prepared: SELECT order_id, customer_id, amount, status FROM orders WHERE status = ?
  [DB]   Query executed (status=DELIVERED limit=4)
  [DB]   ResultSet closed
  Export data preview (first 2 lines):
    order_id,customer_id,amount,status
    ORD-0001,C-1001,500.0,DELIVERED
    ORD-0002,C-1002,1000.0,DELIVERED
  [DB]   Statement closed
  [DB]   Connection closed
Export result: ExportResult{exported=4, file=/exports/delivered.csv}

=== All three resources closed in reverse order ===
  Declared order : Connection → Statement → Writer
  Closed order   : Writer → Statement → Connection

Performance Considerations

try-with-resources has identical runtime performance to an equivalent try-finally block. The compiler generates the same bytecode structure — the only difference is that try-with-resources generates correct exception suppression handling that manual try-finally requires explicit code to achieve.

PERFORMANCE FACTS:

  try-with-resources vs try-finally (equivalent manual code):
    Zero runtime overhead difference
    Same bytecode operations at the JVM level
    Same method call stack depth

  WHERE PERFORMANCE MATTERS:
  — close() method call frequency: each resource's close() is called once
  — Connection pool return cost: depends on the pool implementation
  — File/stream flush cost: depends on buffer state at close time

  WHAT TO WATCH FOR:
  — Never put expensive computation inside close() of a hot-path resource
  — Never suppress close() failures with an empty catch inside close()
  — Multiple resources: each declared resource allocates its own object
    before the try body — if the Nth constructor fails, resources 1 to N-1
    are still closed automatically (the partially-initialized list is safe)

  PARTIAL INITIALIZATION SAFETY:
    try (A a = new A();   ← succeeds
         B b = new B();   ← succeeds
         C c = new C()) { ← THROWS during construction
        // never entered
    }
    Result: b.close() then a.close() — both run safely
    c was never fully initialized — its close() is NOT called (no object exists)

Best Practices

Declare every AutoCloseable resource in try-with-resources — never in a separate variable outside the try. Declaring the resource outside and using it inside loses the automatic close guarantee. If an exception occurs between the declaration and the try block — rare but possible — the resource leaks. The declaration in the try parentheses is the only safe form for AutoCloseable resources.

Design custom AutoCloseable implementations so close() is idempotent. close() may be called more than once in some scenarios — once by try-with-resources and once manually. An idempotent close() that tracks whether it has already been closed prevents IOException or IllegalStateException from a double-close. The JDK's own InputStream.close() is idempotent; follow the same contract.

Never swallow exceptions inside close() with an empty catch block. If close() can fail meaningfully, the failure should be logged at minimum. Silent suppression inside close() makes connection leaks, file corruption, and incomplete flushes invisible. If close() throws, let the exception propagate or log and suppress explicitly — never ignore it.

Use the Java 9 effectively-final variable form when the resource already exists. Connection conn = getExistingConnection(); try (conn) { ... } avoids re-declaring a variable you already have. The requirement: the variable must be effectively final (never reassigned after the point where it is used in the try header). This form is syntactically cleaner when the resource is received as a method parameter or retrieved before the try block.

Common Mistakes

Mistake 1 — Declaring the Resource Outside try-with-resources

Mistake 2 — Assuming Resources Are Closed in Declaration Order

Mistake 3 — Using null in try-with-resources

Mistake 4 — Not Implementing AutoCloseable for Resource-Holding Classes

Interview Questions

Q1. What is try-with-resources and which Java version introduced it?

try-with-resources was introduced in Java 7. It is a try block that declares one or more resources in parentheses — any object implementing java.lang.AutoCloseable. The compiler generates code to call close() on each resource when the block exits, regardless of whether it exits normally, via exception, or via return. It solves two problems with manual try-finally: the risk of forgetting to call close(), and the exception suppression problem where a close() failure in finally replaces the original exception.

Q2. What is the AutoCloseable interface and what does it require?

java.lang.AutoCloseable is the contract that enables try-with-resources. It declares one method: void close() throws Exception. Any class implementing this interface can be declared in try-with-resources parentheses. java.io.Closeable extends AutoCloseable with a narrower signature: void close() throws IOException. JDK I/O classes implement Closeable; JDBC types (Connection, Statement, ResultSet) implement AutoCloseable. When designing a class that holds a resource needing deterministic cleanup, implementing AutoCloseable is the correct pattern.

Q3. In what order are multiple resources closed in try-with-resources?

Resources are closed in reverse order of declaration — Last-In-First-Out. If you declare try (A a = new A(); B b = new B()), b.close() is called first, then a.close(). The rationale is that B was declared after A and may depend on A — closing B while A is still open ensures B.close() can safely use A if needed. This mirrors the stack-like relationship between dependent resources and matches the order natural for connection → statement → result set.

Q4. How does try-with-resources handle the case where both try body and close() throw?

If the try body throws and close() also throws, try-with-resources keeps the original exception as the primary exception and attaches the close() exception as a suppressed exception via primaryException.addSuppressed(closeException). Callers retrieve suppressed exceptions with exception.getSuppressed(). This is the key correctness advantage over manual try-finally: a close() failure in finally silently replaces the original exception. With try-with-resources, the original exception is never lost.

Q5. Can try-with-resources be used with catch and finally blocks?

Yes. try-with-resources can be combined with catch and finally in the same structure. The execution order is: try body → automatic close() calls (reverse order) → catch (if applicable) → finally. The resources are closed before catch and finally execute. This means close() errors can be caught by the catch block if they propagate, and finally runs after all resources are closed — which is the expected behaviour for cleanup that must always happen beyond resource management.

Q6. What is the Java 9 enhancement to try-with-resources?

Java 9 allows using an effectively final variable in the try-with-resources parentheses without re-declaring it. Before Java 9, you had to declare the resource inside the parentheses: try (Connection conn = dataSource.getConnection()). In Java 9+, if you already have an effectively-final reference (never reassigned), you can write try (conn) directly. The variable must not be reassigned between its declaration and the try header. This reduces verbosity when a resource is received as a parameter or retrieved before the try block.

FAQs

What is the difference between AutoCloseable and Closeable?

java.lang.AutoCloseable is the root interface for try-with-resources. Its close() method declares throws Exception — it can throw any checked exception. java.io.Closeable extends AutoCloseable and narrows the declaration to throws IOException. I/O classes implement Closeable; JDBC and other non-I/O resource classes implement AutoCloseable directly. For custom resource classes, implement AutoCloseable and declare the narrowest possible exception on close() — or no checked exception if close() cannot fail.

Does try-with-resources call close() if an exception occurs during resource construction?

If the Nth resource constructor throws, resources 1 through N-1 that were successfully constructed are closed. Resource N was never successfully created, so its close() is not called. The compiler generates the close calls only for resources that were successfully instantiated. This partial-initialization safety is one of the correctness guarantees that makes try-with-resources preferable to manual management.

Can a null resource be used in try-with-resources?

Java 7-8: no — passing null to the try-with-resources mechanism causes NullPointerException when close() is attempted. Java 9+: using an effectively-final variable that is null still causes the same problem. Always ensure the resource reference is non-null before entering try-with-resources. If the resource might legitimately be absent, null-check before and throw or return early.

What happens if close() throws an unchecked exception?

If close() throws an unchecked RuntimeException and the try body completed normally, the unchecked exception propagates to the caller — same as a checked exception. If the try body also threw, the unchecked close exception is attached as suppressed. There is no special treatment for unchecked vs checked in suppression handling — both are suppressed equally.

Can I use try-with-resources for a resource that does not implement AutoCloseable?

No — the resource must implement AutoCloseable. If you are working with a legacy class that holds a resource but does not implement AutoCloseable, you have two options: wrap it in a custom AutoCloseable adapter that delegates close() to the legacy cleanup method, or use manual try-finally. The adapter approach is cleaner for repeated use: class LegacyResourceAdapter implements AutoCloseable { ... @Override public void close() { legacy.release(); } }.

Can try-with-resources be nested, and how does that affect close order?

Yes. Multiple levels of try-with-resources blocks can be nested. Each block manages its own resources independently. The inner block's resources are closed when the inner try exits; the outer block's resources are closed when the outer try exits. This is distinct from declaring multiple resources in one try-with-resources block — nested blocks are completely independent scopes. Nesting is useful when an inner resource needs to be scoped within an outer block: a statement scoped within a connection, for example, can each be in separate blocks if different error handling is needed at each level.

Summary

try-with-resources solves the two fundamental problems of resource management with try-finally: the risk of forgetting close() and silent exception suppression when close() itself throws. The compiler generates the close calls automatically, closes multiple resources in reverse order of declaration, and attaches close failures as suppressed exceptions on the primary exception rather than replacing it.

The AutoCloseable interface is the enabling contract: any class implementing void close() throws Exception can be used in try-with-resources. Custom resource-holding classes should implement AutoCloseable to enable callers to use this syntax. The Java 9 effectively-final variable form reduces verbosity for resources that already exist before the try block.

Three rules govern correct usage: declare resources inside the try parentheses, not outside; know that multiple resources close in reverse order; and make close() idempotent so double-close does not throw. The only remaining use case for manual try-finally is non-AutoCloseable resources — ReentrantLock, custom state management — where try-with-resources cannot be applied without a wrapper.

What to Read Next