Describe the Throwable class hierarchy in Java. What are its two main branches and what does each represent?

## What problem is this solving? When something goes wrong during a program's execution, Java needs a uniform way to signal that failure and a uniform way to respond to it. The mechanism is *exceptions*: an object that describes the failure is created and "thrown", which interrupts normal flow and unwinds the call stack until some code "catches" it. For this to work, every throwable thing must share a common type so that `throw` and `catch` know what they operate on. That common type is **`java.lang.Throwable`**. ## The rule: only Throwable can be thrown or caught The `throw` statement and `catch` clause only accept a `Throwable` (or a subclass). You cannot `throw "oops"` or `catch (String e)`. Every error object in Java is therefore an instance of some class that ultimately extends `Throwable`. ## The two branches `Throwable` has exactly two direct subclasses, and they encode a *contract about who is expected to handle the failure*: ``` Throwable ├── Error (serious, do NOT catch — usually unrecoverable) └── Exception (application conditions — usually recoverable) └── RuntimeException (programming bugs — unchecked) ``` ### Error **`Error`** signals serious problems that a normal application *should not try to catch* because it generally cannot do anything useful about them. These are typically raised by the JVM or the runtime environment, not by your own business logic. Examples: `OutOfMemoryError` (the heap is exhausted), `StackOverflowError` (recursion went too deep and the call stack filled up), `NoClassDefFoundError` (a class that was present at compile time is missing at run time), `AssertionError` (a Java `assert` failed). When an `Error` propagates to the top of a thread, that thread typically dies. ### Exception **`Exception`** signals conditions that a well-written application might reasonably anticipate and recover from — a file that isn't there (`IOException`/`FileNotFoundException`), a network timeout, a parse failure. The intent is that you catch these and do something sensible (retry, show an error, use a default). ### RuntimeException — a sub-branch of Exception Inside `Exception` lives **`RuntimeException`**. These represent *programming mistakes* — situations that, in principle, correct code would have prevented. Examples: `NullPointerException` (dereferencing a null), `IllegalArgumentException` (a method got an argument it forbids), `IllegalStateException` (a method called when the object is in the wrong state), `ClassCastException` (a bad cast), `ArrayIndexOutOfBoundsException`, `NumberFormatException` (e.g. `Integer.parseInt("abc")`), `ConcurrentModificationException` (modifying a collection while iterating it). ## Checked vs unchecked — why the split matters The tree shape drives Java's **checked-exception** rule, enforced by the *compiler* (not the JVM): - **Checked**: everything under `Exception` *except* `RuntimeException` and its subclasses. The compiler forces the calling code to either `catch` it or declare it with `throws`. Forgetting to do so is a compile error. - **Unchecked**: `RuntimeException` (and subclasses) **and** `Error` (and subclasses). The compiler imposes no handling requirement — you *may* catch them but are never *forced* to. So the dividing line for "does the compiler force me to handle it" is: are you a `RuntimeException` or an `Error`? If yes → unchecked. The design intent: programming bugs (`RuntimeException`) and catastrophic JVM problems (`Error`) shouldn't litter every method signature with `throws`, whereas genuinely recoverable, expected conditions (checked `Exception`) should be visible in the API. ## How a learner at each level should hold this Junior: name the root (`Throwable`) and the two branches, and that only Throwable can be thrown/caught. Middle: map checked/unchecked onto the tree and give correct examples in each box. Senior: explain *why* the design separates JVM problems, programming bugs, and recoverable conditions. Principal: reason about API design implications (when to choose checked vs unchecked for your own exceptions).