Catching Throwable is generally bad practice because Throwable is the root of both Exception and Error, so a catch block for it silently swallows serious JVM-level Errors, like OutOfMemoryError or StackOverflowError, alongside ordinary application exceptions, which a well-behaved application usually shouldn't try to recover from.
Key Points: • Errors typically indicate conditions the application can't reliably recover from, such as running out of heap memory or exhausting the stack. • Catching Throwable can mask these serious problems, letting the application limp along in a corrupted or unstable state instead of failing fast and getting restarted or investigated. • It also makes error handling overly broad and imprecise, since it treats all failure types identically, hiding what actually went wrong. • A narrower catch, Exception or a specific exception type, lets errors propagate so monitoring, supervisors, or the JVM itself can respond appropriately, such as a container orchestrator restarting a crashed process. • If Throwable really must be caught, for example at a top-level framework boundary for logging before exiting, it should generally be re-thrown or the process should still terminate rather than continue normal operation.
Example: A service that wraps its whole main loop in catch (Throwable t) might catch an OutOfMemoryError, log it, and keep looping, but the JVM is likely still in a degraded state, so the application keeps failing in confusing ways instead of restarting cleanly.
Interview Tip: A concise interview answer is:
"Throwable is the superclass of both Exception and Error, so catching it also catches serious JVM-level problems like OutOfMemoryError that an application usually can't safely recover from. I'd catch specific exceptions or Exception at most, and let unrecoverable Errors propagate so the process can fail fast and be restarted rather than continuing in a corrupted state."