What is try-with-resources in Java, and why is it preferred over closing resources in a finally block?

## What a "resource" is A **resource** is any object that holds something the operating system or runtime must hand back when you are done: an open file, a network socket, a database `Connection`, an input/output `Stream`, a `Lock`. If you stop using such an object without closing it, the underlying handle stays open. That is a **resource leak**. Leaked file handles or DB connections eventually exhaust a fixed pool or OS limit, and the program starts failing with errors like "too many open files" or "connection pool exhausted" — often long after the buggy code ran, which makes leaks hard to diagnose. ## How cleanup used to be done: finally Before Java 7 you closed resources by hand in a `finally` block. `finally` is a block that always runs after `try`, whether the `try` finished normally or threw an exception. The classic pattern: ```java InputStream in = null; try { in = new FileInputStream(path); // use in } finally { if (in != null) in.close(); } ``` This works but has several traps: 1. **You can forget the finally entirely**, and then the resource leaks on every call. 2. **You need null checks** because the variable might not have been assigned if `new` threw. 3. **The "swallowed exception" bug**: if the `try` body throws exception A, then `in.close()` in `finally` also throws exception B, the `finally`'s exception B *replaces* A as the exception that propagates. The original failure A — usually the one you actually care about — is silently lost. Diagnosing becomes very hard. 4. **Multiple resources** force nested try/finally blocks that are verbose and easy to get wrong. ## try-with-resources (Java 7+) You declare the resource inside parentheses right after `try`: ```java try (InputStream in = new FileInputStream(path)) { // use in } ``` The compiler generates the closing logic for you. The rules: - Any object you declare there must implement **`AutoCloseable`** (or its subinterface `Closeable`), which means it has a `close()` method. Most JDK and library resources already do. - Each declared resource is **automatically closed** at the end of the `try` block, **whether it exits normally or by exception**. - If you declare several, they are **closed in reverse order** of declaration (last opened, first closed), which respects dependencies between them. - **Suppressed exceptions**: if the `try` body throws A and a `close()` throws B, A is the exception that propagates, and B is *attached* to A as a **suppressed exception** (retrievable via `Throwable.getSuppressed()`). Nothing is lost — the reverse of the old finally bug. Since Java 9 you can also list an already-declared effectively-final variable: ```java final var in = openStream(); try (in) { ... } ``` ## Why it is preferred It makes the correct behavior the **default**: you cannot forget the close, you avoid null checks, you avoid the swallowed-exception bug, and you get clear multi-resource handling. It removes a whole class of leaks and lost-stack-trace bugs with less code than the equivalent finally. ## When you still cannot use it If the object you must release does not implement `AutoCloseable` (rare in modern code) or its lifetime does not match a single lexical block (e.g. a connection held across method calls), you fall back to explicit cleanup — but you should still ensure the close runs on every path.