Java Exception Hierarchy
Throwable is the root type for things that can be thrown.
Error represents serious JVM/runtime problems such as StackOverflowError or OutOfMemoryError. Applications usually should not catch these broadly.
Exception represents conditions applications may handle. Checked exceptions are enforced by the compiler. RuntimeException and its subclasses are unchecked.
Handling Strategy
Catch exceptions where you can add meaning, recover, retry, translate to an API response, or clean resources. Avoid swallowing exceptions silently.
Use finally or try-with-resources for cleanup.
Interview Framing
Mention the difference between checked and unchecked exceptions, and explain throw vs throws: throw raises an exception now; throws declares possible propagation from a method.
Interview Scenario Practice
Scenario 1: File Read Failure
Scenario: A method reads a file and the file may not exist.
Strong answer: Handle or declare the checked exception, depending on whether the method can recover or whether the caller should decide.
Why it works: Checked exceptions make expected recoverable failure part of the method contract.
Common mistake: Catching the exception and doing nothing, which hides the failure.
Scenario 2: Invalid Method Argument
Scenario: A method receives a negative age.
Strong answer: Throw an unchecked exception such as IllegalArgumentException because the caller violated the method contract.
Why it works: Programming errors and invalid arguments are commonly represented with runtime exceptions.
Common mistake: Returning magic values like -1 for every error.
Scenario 3: Resource Cleanup
Scenario: A database or file resource must be closed even if an exception occurs.
Strong answer: Use try-with-resources for AutoCloseable resources, or finally for cleanup that must always run.
Why it works: Cleanup is guaranteed even when control flow exits through an exception.
Common mistake: Closing resources only at the end of the happy path.