Exceptions and resource lifetimes

Preserve the cause and the boundary

Checked exceptions are part of a method's declared failure contract. IOException says the operation may fail for environmental reasons; IllegalArgumentException says the caller violated a value contract. Catch where you can recover, translate with context, or perform required cleanup. Catching Exception and returning zero silently turns failure into valid-looking data. Retain the original cause when wrapping; a stack trace without the causal failure loses the mechanism needed to diagnose it.

finally runs on ordinary return and exception propagation, but a return/throw inside finally can replace the original outcome. Avoid it. Errors such as OutOfMemoryError generally are not useful application recovery points. Design the narrowest useful throws contract rather than mechanically catching every checked exception.

Resources have lifetimes beyond reachability

Garbage collection reclaims heap memory; it does not provide timely closure of file handles, sockets, or locks. AutoCloseable makes deterministic cleanup composable with try-with-resources. Resources close in reverse declaration order. If both the body and close fail, the body exception stays primary and the close failure becomes suppressed; inspecting only getCause misses suppressed errors.

try (var reader = new StringReader("text")) {
    assert reader.read() == 't';
}

That syntax establishes ownership of the reader's lifetime. An API accepting a caller-owned reader must explicitly say whether it closes it; the type alone cannot answer. Wrapping a reader in BufferedReader and closing the wrapper closes the underlying reader as well. Reading the entire input before parsing can waste memory; a line-by-line reduction keeps workspace bounded by the largest line. Test cleanup during both successful execution and failures, and test what happens when cleanup itself throws. Finalizers and System.gc are not substitutes for a resource protocol.