12.2. Exception Hierarchy in Java

java.lang.Throwable ├── Error │ └── e.g., OutOfMemoryError, StackOverflowError └── Exception ├── Checked Exceptions │ └── e.g., IOException, SQLException └── Unchecked Exceptions (RuntimeException) └── e.g., NullPointerException, ArithmeticException

In Java, all exceptions and errors are represented within a hierarchy. At the top of this hierarchy is the class Throwable. It has two primary subclasses: Error and Exception.

• Error signifies serious issues that a program usually cannot recover from, such as OutOfMemoryError and StackOverflowError. These errors indicate problems with the Java Virtual Machine (JVM) and are not expected to be handled in application code.
• Exception, on the other hand, is further divided into Checked Exceptions and Unchecked Exceptions.
  • Checked Exceptions must be either caught or declared in the method signature using the throws keyword. Examples are IOException and SQLException, which typically involve errors beyond a developer's control like file handling issues.
  • Unchecked Exceptions, also known as RuntimeExceptions, do not require explicit handling at compile time, but developers are expected to handle them wisely. Examples include NullPointerException, which occurs when program attempts to use a null reference, and ArithmeticException, which happens when there is an illegal arithmetic operation, such as division by zero.

Think of the exception hierarchy like a family tree: At the very top, you have the Throwable parent, representing all issues that can arise. The Error branch represents serious, life-altering problems (like a tree that has fallen on a house), which cannot be fixed simply. The Exception branch represents more manageable issues. Among them, some issues, like checking for a guest's age before letting them into a bar (Checked Exceptions), must be handled proactively. Others, like someone tripping and falling (Unchecked Exceptions), are things that can occur at any moment, and while we should try to avoid them, they might happen without warning.

Checked Exceptions ├── e.g., IOException, SQLException

Unchecked Exceptions (RuntimeException) ├── e.g., NullPointerException, ArithmeticException

Exceptions in Java are categorized into two main types based on how they are handled in the programming process:

• Checked Exceptions: These exceptions are checked by the Java compiler at compile time. Developers must handle them, or the code will not compile. Examples include IOException, which occurs while trying to read or write a file that may not exist, and SQLException, which arises from database operation failures. Handling these exceptions is crucial because they pertain to scenarios that are often out of the developers' hands.

• Unchecked Exceptions: These do not require explicit handling during the compile time as they are checked at runtime. This category includes exceptions like NullPointerException, which occurs when you attempt to use an object that is not initialized, and ArithmeticException, which happens when there’s an illegal arithmetic operation like division by zero. While it’s not mandatory to handle them, doing so can prevent unexpected application crashes.

Imagine you're preparing for a party. A Checked Exception is like forgetting to send out invitations; you need to send them out or your guests won't know they’re invited, and there will be no party. You must take action before the party (compile time). An Unchecked Exception, on the other hand, is like running out of ice on the day of the party; it's unexpected and all you can do is try to fix it without missing a beat. You may not plan for it (runtime), but you need to have the readiness to handle it if it happens!

--