When designing a custom Java exception, what is the difference between a checked and an unchecked exception, and how do you decide which one to extend?

## What an exception is An **exception** in Java is an object that represents an abnormal event interrupting normal program flow. When code hits a problem it `throw`s an exception object; the JVM then unwinds the call stack looking for a matching `catch` block. All exceptions descend from the class `Throwable`. ## The Throwable hierarchy - `Throwable` is the root. - `Error` — serious problems the application should NOT try to handle (e.g. `OutOfMemoryError`). Treated like unchecked. - `Exception` — the base for application-level problems. - `RuntimeException` — a special subclass of `Exception`. The single rule that decides 'checked vs unchecked' is purely about position in this tree: - **Checked** = a subclass of `Exception` that is NOT a subclass of `RuntimeException`. - **Unchecked** = a subclass of `RuntimeException` (or of `Error`). ## What 'checked' means mechanically The Java **compiler** enforces a rule for checked exceptions called the *catch-or-declare requirement* (also 'handle or declare'). If a method body can throw a checked exception, the method must either: 1. wrap the call in a `try/catch` that handles it, or 2. add `throws ThatException` to its own signature, pushing the obligation to its callers. If you do neither, the code does **not compile**. Unchecked exceptions have no such requirement — you may throw them anywhere with zero ceremony, and the signature need not mention them. ## How you make a custom exception checked or unchecked You choose by which class you extend: ```java class InvalidConfigException extends Exception {} // checked class MissingConfigKeyException extends RuntimeException {} // unchecked ``` Nothing else distinguishes them — there is no keyword or annotation. ## The design decision (the real subject of this leaf) The authoritative guidance, from Joshua Bloch's *Effective Java*: - Use a **checked** exception when the caller can **reasonably be expected to recover**. By making it checked you force the caller to confront the failure at compile time. Example: a payment gateway timeout where the caller might retry, or a parse error where the caller can ask for different input. - Use an **unchecked** (runtime) exception for **programming errors** — precondition violations the caller should simply have avoided. Examples: passing `null` where it is illegal (`NullPointerException`), an out-of-range index (`IndexOutOfBoundsException`), or calling a method in the wrong state (`IllegalStateException`). Recovery is not the point; fixing the bug is. - For conditions where recovery is **impossible or implausible**, prefer unchecked too — forcing a `catch` no one can act on just adds noise. ## Trade-offs **Checked pros:** the failure is part of the API contract; the compiler guarantees callers acknowledge it; failures cannot be silently ignored. **Checked cons:** boilerplate (`throws` clauses everywhere, ceremonial `try/catch`); they leak through abstraction layers — a low-level `SQLException` propagating up forces unrelated upper layers to know about it; they compose badly with lambdas/streams (functional interfaces don't declare checked exceptions); they tempt developers into the worst anti-pattern, the empty `catch {}` that swallows the error. **Unchecked pros:** clean signatures, friendly to streams/lambdas, no leaky `throws`. **Unchecked cons:** failures are invisible in the type system, so callers may not know to handle them — documentation (Javadoc `@throws`) must compensate. ## The modern trend Many influential Java frameworks (Spring, Hibernate) deliberately use **unchecked** exceptions almost everywhere, wrapping checked ones (e.g. Spring's `DataAccessException` hierarchy wraps `SQLException`). Languages after Java — Kotlin, Scala, C# — dropped checked exceptions entirely. The consensus in much of the industry is that checked exceptions cost more in boilerplate and leaky abstractions than they pay back, so default to unchecked and reserve checked for the rare case where a caller genuinely should be forced to handle a recoverable failure. The opposing view (still defended) is that checked exceptions are a valuable, compiler-verified part of an API contract and overuse of unchecked exceptions hides real recoverable failures. ## Putting it together When you author a custom exception, ask: *Is this a bug the caller should have prevented, or a legitimate runtime condition they might recover from?* Bug or unrecoverable → extend `RuntimeException`. Recoverable and the caller should be forced to deal with it → extend `Exception`. When in doubt in modern code, lean unchecked and document it.