What is the difference between checked and unchecked exceptions, and how does that distinction map onto the Throwable hierarchy?

## The core idea "Checked" and "unchecked" describe whether the **Java compiler forces you to deal with an exception**. This is a property determined entirely by *where a class sits in the `Throwable` hierarchy*, and it is enforced at *compile time* — the JVM at runtime makes no such distinction. ## Defining the boundary on the tree ``` Throwable ├── Error → UNCHECKED └── Exception → CHECKED ... └── RuntimeException → UNCHECKED (the carve-out) ``` The rule, precisely: - A class is **unchecked** if it is `Error`, or `RuntimeException`, or any subclass of either. - A class is **checked** if it is `Exception` (or a subclass) but **not** in the `RuntimeException` sub-tree. So `IOException`, `SQLException`, `InterruptedException`, `ClassNotFoundException` are checked. `NullPointerException`, `IllegalArgumentException`, `ArithmeticException`, `ClassCastException` are unchecked (they're RuntimeExceptions). `OutOfMemoryError`, `StackOverflowError` are unchecked (they're Errors). ## What "the compiler forces you" actually means If a method body can throw a *checked* exception, the compiler requires one of two things in the **calling** method: 1. **Handle it** — wrap the call in `try { ... } catch (TheCheckedException e) { ... }`, or 2. **Declare it** — add `throws TheCheckedException` to the method signature, passing the obligation up to *its* caller. If you do neither, the code does not compile ("unreported exception ... must be caught or declared to be thrown"). For an *unchecked* exception, none of this applies — you may catch it, declare it, or ignore it entirely, and the code compiles regardless. ```java // Checked: must catch or declare — this WON'T compile as-is void read() { new FileInputStream("x"); // throws FileNotFoundException (checked) } // Fix 1: declare void read() throws FileNotFoundException { new FileInputStream("x"); } // Unchecked: compiles with no try/catch and no throws void parse(String s) { Integer.parseInt(s); // may throw NumberFormatException (unchecked) } ``` ## Why the language designers drew the line here - **Checked exceptions** are meant for conditions that are *outside the program's control but anticipatable* — the file might be missing, the network might drop. Making them checked puts the failure mode into the method's published contract (its `throws` clause), forcing callers to consciously decide what to do. - **`RuntimeException` (unchecked)** is meant for *programming errors* — a null you forgot to guard, an index past the end of an array. In principle correct code wouldn't hit them, so the language doesn't burden every method with declaring them. You *fix the bug* rather than routinely catch them. - **`Error` (unchecked)** is for *grave, typically unrecoverable* JVM/environment failures. There's usually nothing useful to do, so forcing handling would be pointless ceremony. ## Trade-offs and debates Checked exceptions are somewhat controversial. Pros: explicit, self-documenting failure modes the compiler verifies. Cons: they couple callers to implementation details, encourage `throws Exception` blanket declarations or empty `catch` blocks that swallow problems, and interact poorly with lambdas/streams (functional interfaces like `Function` don't declare checked exceptions). Many modern frameworks (e.g. Spring) lean heavily on *unchecked* exceptions for this reason. Knowing the boundary lets you make a deliberate choice when designing your own exception types. ## Practical tells - See it in a `throws` clause and the compiler complains if you remove it → checked. - It compiles fine with no handling at all → unchecked (RuntimeException or Error).