When you catch an exception you cannot fully handle, what are your options, and how do you preserve the original cause?

## The situation You are in a `catch` block. The exception is real, but **this layer cannot meaningfully fix it** — a data-access class catches a `SQLException`, but it can't decide whether to retry, show an error page, or abort; that's the caller's job. Swallowing is wrong (the error must not vanish). So you **propagate**: send the failure onward. ## Option 1 — rethrow unchanged The simplest propagation is to re-throw what you caught: ```java catch (IOException e) { metrics.increment("io.failure"); // do a side task, but don't handle throw e; // let the caller deal with it } ``` Use this when you only wanted to observe the failure (log it, record a metric) but the *handling* belongs higher up. The original stack trace is untouched. ## Option 2 — wrap and rethrow (exception translation) Often you want to **translate** a low-level exception into one that fits your layer's abstraction, so callers don't depend on implementation details. A repository shouldn't make every caller know about JDBC's `SQLException`; it throws a domain `RepositoryException` instead: ```java catch (SQLException e) { throw new RepositoryException("failed to load user " + id, e); // note the 'e' } ``` The **second argument** `e` is the **cause**. It is the whole point. ## What 'cause' and 'chaining' mean Every `Throwable` can hold a reference to another `Throwable` that caused it — its **cause**. You set it via a constructor that takes `(String message, Throwable cause)` or via `initCause(Throwable)`. This forms a linked chain: top-level exception → its cause → that cause's cause, and so on. When the chain is printed, you see: ``` RepositoryException: failed to load user 42 at UserRepo.load(UserRepo.java:31) ... Caused by: java.sql.SQLException: connection reset at ... ``` The `Caused by:` section is the original problem. Without it, you'd see only 'failed to load user 42' and have no idea the real issue was a dropped DB connection. ## The cardinal mistake: dropping the cause ```java catch (SQLException e) { throw new RepositoryException("failed to load user " + id); // BUG: no cause! } ``` This is almost as harmful as an empty catch. The new exception propagates, but the original `SQLException`'s message and stack trace are gone — you lose the root cause. A common variant is `throw new RuntimeException(e.getMessage())`, which keeps only the text and loses the type and trace. Always pass the exception object itself. ## When NOT to wrap Wrapping adds a layer; do it only when it adds value (a clearer message or a layer-appropriate type). If the caught exception is already meaningful to the caller, a plain rethrow is cleaner. Avoid wrapping an exception in the *same* type for no reason, and avoid double-wrapping that produces deep, noisy chains. ## Checked vs. unchecked while propagating If you rethrow a checked exception, your method must declare it with `throws` (or wrap it in an unchecked one to cross an API where you don't want a checked signature). Wrapping a checked `SQLException` into an unchecked `RepositoryException extends RuntimeException` is a common way to remove checked-exception noise from a clean domain API — but only if your team has decided that policy.