Catching Exception vs Throwable in Java
Fast recall
Quick revision
Core answer
catch (Exception) catches checked and unchecked exceptions under Exception; it does not mean every case is recoverable. catch (Throwable) also catches Error, including failures ordinary application code should usually let propagate. Catch the narrowest type you can handle; broad catches belong mainly at well-defined boundaries and must not silently swallow serious failures.Whether you understand that Throwable includes Error and why catching Error is dangerous
Using catch (Throwable) thinking it's safest, which swallows Errors that should terminate the process
Note that the only legitimate Throwable catch is framework/thread-pool code that must log a fatal error before shutting the component down
Interview-ready guide
Interview answer
Catching Exception includes checked exception types and RuntimeException subclasses, but it does not include the separate Error branch. Catching Throwable includes both Exception and Error, so it can intercept conditions ordinary application code is not prepared to recover from.
For example, an HTTP boundary may catch Exception to turn an unexpected request failure into a 500 response while recording it. Catching Throwable there could also catch OutOfMemoryError, after which constructing a response may itself be unsafe. Carefully designed infrastructure may catch Throwable briefly to record task termination or run required cleanup, but it should preserve interruption and rethrow anything it cannot safely handle. In ordinary code I catch the narrowest type for which I have a real recovery, translation, or cleanup action.
Catching Exception vs Throwable in Java
Direct Answer
catch (Exception) catches checked and unchecked exceptions under Exception; it does not mean every case is recoverable. catch (Throwable) also catches Error, including failures ordinary application code should usually let propagate. Catch the narrowest type you can handle; broad catches belong mainly at well-defined boundaries and must not silently swallow serious failures.
Common Mistakes & Pitfalls
- Catching
Throwableto 'be safe'. It's the opposite of safe — it swallowsErrors likeOutOfMemoryErrorthat should crash the process. - Thinking
catch (Exception)catchesOutOfMemoryError. It doesn't;Errorlives outside theExceptionbranch and propagates past it. - Continuing after catching an
Error. The JVM state is undefined, so recover-and-continue risks corrupting data. - A blanket
catch (Exception)everywhere. Prefer the most specific type you can actually act on; keep a broad catch only at the top level.
Check your understanding
Answer these without looking back at the article.
- Is there a case where catching OutOfMemoryError makes sense?
- What is a global exception handler in Spring MVC?
- How does catching Exception differ from catching RuntimeException?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.