Throwable Class Methods in Java

Throwable is the root of the exception hierarchy, but it's also where all the diagnostic plumbing lives, so every exception inherits these methods. The most basic one is getMessage, which returns the human-readable description you passed into the constructor. The one I'd really emphasise, because freshers often miss it, is getCause. That returns the underlying exception that triggered this one, and it's the basis of exception chaining. Say your data layer throws a S Q L exception but your service layer wants to throw its own domain exception — you pass the S Q L exception in as the cause, so later anyone can call getCause and recover the original error, including the database error code. If you don't preserve that cause, you've thrown away the information you'll need to debug the problem in production. Then there's printStackTrace, which everyone knows from tutorials — it dumps the full call stack to standard error. That's fine for a quick local check, but in production you shouldn't use it because it bypasses your logging framework. Instead you use getStackTrace, which gives you the stack frames as an array of StackTraceElement objects that a logger can format properly. There's also addSuppressed and getSuppressed, which carry secondary exceptions; that's how try-with-resources records a failure from closing a resource without losing the primary exception. The big mistake to avoid is wrapping an exception and forgetting to pass the original as the cause, because then the chain is broken and your logs show the wrapper but not the actual reason. When I debug, I walk the cause chain by calling getCause repeatedly, because the real culprit is often a few layers down.