Exceptions

Throwable is the root of everything that can be thrown or caught. It has two direct subclasses: Error, which signals serious JVM-level failures like OutOfMemoryError you are not meant to catch, and Exception, which models application problems. Exception's own subclass RuntimeException is unchecked, while every other Exception is checked.

throw is a statement inside a method body that actually raises a single exception instance right now, e.g. throw new IOException(). throws is a clause in the method signature that declares which checked exceptions the method may propagate to its caller, so the caller knows to catch or re-declare them. One acts; the other documents.

Checked exceptions are subclasses of Exception excluding RuntimeException; the compiler forces every caller to either catch them or declare them with throws, so they model recoverable conditions like a missing file. Unchecked exceptions, subclasses of RuntimeException and Error, need no declaration and usually signal programming bugs or fatal conditions you are not expected to recover from.

Java scans the catch clauses top-down and enters the first one whose type is assignable from the thrown exception, so the subclass has to come first: catch (FileNotFoundException e) and only then catch (IOException e). In the opposite order the broad clause already handles the subclass, the narrow one becomes unreachable, and the compiler rejects it outright.

Declare both resources in one try header, separated by a semicolon. They are closed in reverse order of declaration, so the program prints open A, open B, close B, close A. Reverse order is guaranteed by the language, because a later resource is often built on an earlier one. Every declared resource is closed even if a previous close() threw — that failure is not lost, it is recorded on the propagating exception as a suppressed one.

It declares one or more resources in parentheses after try, and the JVM closes them automatically at the end of the block — in reverse order of opening — by calling close() on each. The resource must implement AutoCloseable. Closing happens whether the block exits normally or via an exception, so you never write a finally to release files or streams. If both the body and close() throw, the close() failure becomes a suppressed exception.

Give the custom type a (String, Throwable) constructor that forwards to super(message, cause), then rethrow with throw new UserLoadException(message, e);. Throwable itself stores that cause, so getCause() returns the SQLException and printStackTrace prints its frames under Caused by:. Passing only e.getMessage() into a message-only constructor keeps the text and silently discards the original stack trace.

If the try body throws and close() then throws too while the block unwinds, the body's exception is the one that propagates, and the close() failure is attached to it by addSuppressed() instead of replacing it. You read those secondary failures back with Throwable.getSuppressed(), and printStackTrace lists them under Suppressed:. A hand-written try/finally has the opposite bug — an exception from the finally replaces the original.

One catch clause may list several exception types separated by | — catch (IOException | SQLException e) — so a shared handler body is written once instead of copied per type. The alternatives may not stand in a subtype relationship with each other: catch (IOException | FileNotFoundException e) is a compile error. The parameter is implicitly final, and its static type is the nearest common supertype of the listed alternatives.

Almost never. Error marks a JVM-level failure the application is not expected to recover from: after an OutOfMemoryError or a StackOverflowError the heap or the stack is already compromised, so a handler that carries on runs on untrustworthy state. The narrow legitimate uses are a top-level handler that logs and then exits, and a framework isolating one task. The real hazard is catch (Throwable t) in ordinary code — it swallows every Error silently.

Give the domain a small unchecked hierarchy — AppException with NotFoundException and ConflictException — and translate at each boundary. The repository catches SQLException and rethrows the domain type with the original as its cause, so the database error still shows up under Caused by:. The controller maps those types onto 404/409/500 and never sees SQLException, keeping HTTP out of the lower layers. A layer that cannot act on a failure lets it propagate rather than swallowing it.

Checked exceptions buy a compiler-enforced contract, but they do not compose: a checked type infects every caller's signature, cannot escape a lambda handed to Stream.map (the functional interfaces declare no throws), and adding one in a minor release breaks source compatibility. That pressure produces the two familiar anti-patterns — the empty catch (Exception e) and a blanket throws Exception. Policy: unchecked by default, checked only where a caller can realistically recover.

Most of the cost is fillInStackTrace, run when the exception is constructed: it walks the call stack to capture every frame, which is far more expensive than a branch. So replacing an if null-check with catching a NullPointerException runs orders of magnitude slower under load and obscures intent. If a trace is genuinely unneeded you can override fillInStackTrace or use -XX:-StackTraceInThrowable, but the real fix is to test conditions explicitly.

finalize() was an Object hook the garbage collector called before reclaiming an object, meant for last-chance cleanup. It is discouraged because the GC runs it non-deterministically — possibly never — it slows collection, can resurrect an object by leaking this, and may mask exceptions it throws. Deprecated since Java 9, it is replaced by try-with-resources for deterministic release and Cleaner for backstop cleanup.

Fix the silent failures first: an empty catch and a bare printStackTrace both lose the error, so each becomes a logged rethrow or a commented decision to ignore. Restore causes next — pass the caught exception into the BillingException constructor — a missing cause makes an incident unresolvable. Only then narrow throws Exception, one leaf method at a time, so callers keep compiling. Prove it with tests asserting the exception type and its cause, not just that a call failed.