Module: | Classes, Objects, OOPs & Inheritance
Q42: Consider the following statements regarding the Throwable Exception Hierarchy in Java:
1. The java.lang.Throwable class is the supreme root class of the Java Exception Hierarchy, directly inherited by exactly two primary subclasses: Error and Exception.
2. The Error subclass represents abnormal, unrecoverable conditions such as OutOfMemoryError or StackOverflowError that reasonable applications should not attempt to catch.
3. The Exception class and all of its subclasses (including RuntimeException) are collectively categorized as Unchecked Exceptions by the Java compiler.
Which of the above statements is/are correct?
2. The Error subclass represents abnormal, unrecoverable conditions such as OutOfMemoryError or StackOverflowError that reasonable applications should not attempt to catch.
3. The Exception class and all of its subclasses (including RuntimeException) are collectively categorized as Unchecked Exceptions by the Java compiler.
Which of the above statements is/are correct?
✅ Correct Answer: A
🎯 Quick Answer:
The correct combination is 1 and 2. Statement 3 is incorrect because the Exception class itself and the majority of its subclasses (like IOException or SQLException) are strictly categorized as Checked Exceptions. Only RuntimeException and its direct subclasses are categorized as Unchecked Exceptions.Structural Breakdown: At the absolute top sits the Throwable class.
It splits into two branches: Error (severe JVM problems like memory exhaustion) and Exception (programmatic issues). The Exception branch further splits into Checked Exceptions (compile-time checked) and RuntimeExceptions (Unchecked). Historical/Related Context: Java's architects designed this strict hierarchy to force developers to differentiate between critical system failures (Errors) which should naturally crash the program, and anticipated environmental issues (like a missing file) which the program should elegantly handle and recover from.
Causal Reasoning: If all Exceptions were unchecked, developers would constantly forget to write fallback logic for common failures like network timeouts.
By strictly enforcing the Checked Exception category at compile-time, Java structurally guarantees more resilient enterprise applications.