try-with-resources.

Hook: Interviewers love this one because it looks like a small syntax feature, but it secretly tests resource cleanup, exception flow, and whether you can avoid leaks under pressure.

Question: What is try-with-resources in Java?

Answer: Try-with-resources is a try block that automatically closes resources such as files, sockets, and JDBC objects when the block ends. The resource must implement AutoCloseable (a contract that says, 'I know how to close myself'). Java closes the resource even if an exception is thrown, which makes code shorter and safer than manual cleanup.

Interview-Ready Answer: I use try-with-resources whenever I open something that must be closed, like a file, socket, scanner, or database connection. I declare the resource in the try header, and Java closes it automatically at the end of the block, even if the body throws. A nice detail is that multiple resources close in reverse order, and if both the body and close() fail, the body exception wins while close failures are kept as suppressed exceptions. Since Java 9, I can also reuse an effectively final local variable in the resource list, which makes cleanup easier to write and harder to forget.

What it is

Detailed Explanation: Try-with-resources is Java’s built-in pattern for automatic cleanup. A resource is any object that holds something external and must be released later, such as a file handle, database connection, or network socket. The key idea is simple: open it, use it, and let Java close it for you no matter how the block exits.

How it works under the hood

1. Java evaluates the resource expressions from left to right and stores them in hidden local variables.
2. If one resource fails to initialize, any earlier resources that were already opened are closed automatically in reverse order.
3. When the body finishes normally, Java closes the resources from last declared to first declared, which is called LIFO order: last in, first out.
4. If the body throws an exception, that exception becomes the primary exception. A primary exception is the main failure that will be reported to the caller.
5. If close() also throws, Java does not lose that error; it attaches it to the primary one as a suppressed exception, meaning a secondary exception that is recorded instead of replacing the main one.
6. The compiler desugars this syntax into try/finally-style code, so the feature is mostly syntax sugar with stronger safety guarantees.

When and why to use it

Use it whenever the object represents a closeable external resource. That includes InputStream, Reader, Socket, Channel, JDBC Connection, PreparedStatement, and ResultSet. It is especially valuable in exception-heavy code, because human beings are bad at remembering cleanup in every branch.

Important details interviewers probe

1. Order matters: resources close in reverse order. If resource B depends on resource A, declare A first and B second.
2. Null is safe: if the resource expression evaluates to null, Java skips the close call instead of throwing a NullPointerException.
3. Java version note: the feature arrived in Java 7. In Java 9, you can put an effectively final existing variable inside the resource header, not only a new declaration.
4. Performance: the overhead is tiny, basically a few extra references and close calls. Complexity is O(n) for n resources because Java closes each one once; in real systems, the I/O work dwarfs this cost.
5. Rule of thumb: if the object has a close() method and represents a scarce external handle, try-with-resources is usually the right default.

Memory hook: Think of it like leaving a hotel room: you can walk out in any mood, but housekeeping still comes in to lock the door behind you. If the room already had a problem, the cleaning issue gets written down as a note instead of replacing the main complaint.

Real-World Example: Imagine a checkout service that talks to a PostgreSQL database on every payment. It opens a Connection, runs a PreparedStatement, and reads a ResultSet for inventory and order writes. If one error path forgets to close the connection, the pool slowly fills up, and after enough traffic the app starts timing out with messages like Connection is not available, request timed out after 30000ms.

What goes wrong in the incident: a developer manually closes the statement in one branch but misses the result set in another, or closes things in the wrong order. Users see checkout spinning, retries failing, and the logs show pool exhaustion rather than a clear business error. Try-with-resources fixes the leak by making the cleanup automatic and consistent, which is exactly what a high-traffic production service needs.

Follow-up & Tricky Questions:

• What order are multiple resources closed? They are closed in reverse declaration order, so the last resource opened is the first one closed. This matters when a later resource depends on an earlier one, like a writer wrapped around a file stream.
• What happens if the body throws and close() also throws? The body exception is the primary exception, and the close failure is added as a suppressed exception. That way you do not lose the real failure that caused the operation to fail.
• Can a try-with-resources variable be null? Yes. If the expression evaluates to null, Java simply skips the close call, so there is no NullPointerException during cleanup.
• What interface must a resource implement? It must implement AutoCloseable. Closeable is a narrower I/O-specific interface that extends it, but AutoCloseable is the general contract.
• What changed in Java 9? You can use an existing effectively final variable in the resource list instead of always declaring a new one in the header. That makes refactoring cleaner when the resource was created earlier.
• Does the finally block run before or after resources close? If you attach a finally to a try-with-resources statement, Java closes the resources first, then runs the finally block. This ordering is a common exam trap.
• Does try-with-resources replace all finally blocks? No. It replaces cleanup for closeable resources, but you may still need finally for non-resource actions like restoring thread-local state or releasing a lock.
• Should I catch and ignore close exceptions? Usually no. If close failures matter, log or handle them carefully; if there is already a primary exception, the close failure is usually best kept as suppressed for later debugging.

• Tricky: If one resource constructor fails, do earlier ones leak? No. Previously opened resources are closed automatically in reverse order before the exception escapes, which is one of the biggest safety wins of this feature.
• Tricky: Is try-with-resources just shorter syntax? No. It also changes error handling by preserving suppressed exceptions, which is critical when cleanup itself can fail.
• Tricky: Can I manually call close() inside the block? You can, but usually should not. Doing so risks double-close bugs or confusing state, and the whole point of the feature is to centralize cleanup automatically.

Common Mistakes:

• Forgetting that close order is reverse order; correction: declare dependent resources from outermost to innermost.
• Calling close() manually inside the block; correction: let try-with-resources own cleanup to avoid double-close bugs.
• Ignoring suppressed exceptions; correction: inspect getSuppressed() when debugging cleanup failures.
• Using try-with-resources for non-closeable work; correction: reserve it for objects that truly represent a resource to be released.

Memory Hook: 'Open it, use it, leave it to Java, and if the exit door squeaks, Java writes that squeak down instead of losing the main problem.'

Cheat Sheet:

• Use it for anything that implements AutoCloseable.
• Resources close automatically, even on exceptions and returns.
• Multiple resources close in reverse order.
• Body exception is primary; close failures become suppressed.
• Java 7 introduced the feature; Java 9 allowed effectively final resource variables.
• It is the default choice for files, sockets, and JDBC objects.

Practice Tasks:

• Wrap a BufferedReader around a file and print the first line.
• Create two custom AutoCloseable classes and verify the close order with print statements.
• Modify the demo so both the body and close() fail, then inspect the suppressed exceptions.