Exception Hierarchy

## Background: what an exception is In Java, when something goes wrong at runtime, the program creates an **exception object** and 'throws' it. Throwing means normal execution stops and the JVM looks back up the chain of method calls (the **call stack**) for code that can **handle** the problem with a `try { ... } catch (SomeException e) { ... }` block. If no handler is found, the program crashes and prints a stack trace. ## The exception class hierarchy Everything throwable descends from the class `Throwable`. Below it there are two main branches: ``` Throwable ├── Error (e.g. OutOfMemoryError, StackOverflowError) -> UNCHECKED └── Exception ├── RuntimeException (e.g. NullPointerException, │ IllegalArgumentException, │ ArrayIndexOutOfBoundsException) -> UNCHECKED └── (everything else: IOException, SQLException, ...) -> CHECKED ``` The categorization rule is purely structural: - **Checked** = a subclass of `Exception` that is **NOT** a subclass of `RuntimeException`. - **Unchecked** = a subclass of `RuntimeException`, OR a subclass of `Error`. Note `RuntimeException` itself extends `Exception`, but it (and its descendants) are carved out as unchecked. ## What 'checked' actually means: the catch-or-declare rule The word 'checked' refers to a **compile-time** check the Java compiler performs. If a piece of code can throw a checked exception, the compiler forces you to do one of two things, or your code will not compile: 1. **Catch** it: wrap the call in `try { ... } catch (IOException e) { ... }`. 2. **Declare** it: add `throws IOException` to the enclosing method's signature, pushing the obligation onto whoever calls your method. This is called the **catch-or-declare** (or 'handle-or-declare') requirement. The compiler tracks, for every statement, which checked exceptions could escape, and verifies one of the two options is satisfied. Unchecked exceptions are exempt: you *may* catch them, but the compiler never *requires* it, and you don't have to list them in `throws`. ## Why two categories? The design rationale The original intent: **checked exceptions model recoverable, expected-but-abnormal conditions** that a well-written caller should consciously deal with — a file that doesn't exist, a network connection that drops. By forcing acknowledgment at compile time, the language tries to prevent you from silently ignoring these. **Unchecked exceptions model two other things:** - `RuntimeException` subclasses model **programming errors / bugs** — dereferencing null, passing an illegal argument, indexing past the end of an array. These can occur almost anywhere, so requiring `throws` on every method would be unbearable; and the right fix is usually to correct the code, not to catch the exception. - `Error` subclasses model **serious, usually unrecoverable JVM-level problems** — running out of memory, stack overflow. Application code generally should not try to catch or recover from these. ## The criticism of checked exceptions Checked exceptions are controversial. Common complaints: - **Boilerplate**: long `throws` lists or `try/catch` clutter. - **Leaky abstractions**: a low-level `SQLException` propagates `throws SQLException` up through many layers that shouldn't know about SQL. - **Encourages swallowing**: developers under pressure write empty `catch` blocks (`catch (IOException e) {}`), which hides errors — worse than not checking at all. - **Poor fit with generics, lambdas, and streams**: functional interfaces like `Function` don't declare checked exceptions, so checked exceptions are awkward inside lambdas. Because of this, many modern Java libraries (and other JVM languages such as Kotlin) avoid checked exceptions entirely, wrapping them in unchecked exceptions instead. Java itself never added new checked-exception-style features after the early years. ## Practical guidance - Throw a **checked** exception when the caller can realistically **recover** and you want to *force* them to consider it. - Throw an **unchecked** exception for **programming errors** (invalid arguments, illegal state) and when forcing handling would only add noise. - When crossing an architectural boundary, **translate** a low-level checked exception into a domain-specific exception (often unchecked) so callers don't depend on implementation details — but keep the original as the **cause** (`new MyException("msg", e)`) so the stack trace is preserved.