Caused By — Nested Exceptions in Java Stack Traces
Fast recall
Quick revision
Core answer
Caused by: shows that one throwable wraps another as its cause. Java prints the outer failure first and then the cause chain, which preserves both higher-level operation context and lower-level detail. The last cause is the deepest recorded cause, but diagnosis should use the full chain rather than assuming the last message alone is the root problem.
Interview-ready guide
Interview answer
Caused by: means a throwable has wrapped another throwable as its cause. A repository might catch SQLException and throw OrderLoadException("Could not load order 42", sqlException). The outer exception says which operation failed, while the cause keeps the database type, message, and frames. Java prints the wrapper first and then each cause, sometimes abbreviating shared frames with ... n more. I follow the whole chain. The last cause is the deepest recorded failure, but it is not automatically the code change to make: a connection refusal may come from wrong configuration, and a parsing failure may come from invalid input supplied higher up. I also check Suppressed: blocks separately because try-with-resources can preserve a close failure there.
Caused By — Nested Exceptions in Java Stack Traces
Direct Answer
Caused by: shows that one throwable wraps another as its cause. Java prints the outer failure first and then the cause chain, which preserves both higher-level operation context and lower-level detail. The last cause is the deepest recorded cause, but diagnosis should use the full chain rather than assuming the last message alone is the root problem.
Deep Dive & Architecture
Java exceptions can retain another throwable in their cause field. A repository may catch SQLException and throw DataAccessException("Could not load order 42", cause). The outer exception explains the failed operation; the cause preserves the database detail and frames.
The printed trace nests each cause under Caused by: and may abbreviate shared frames with ... n more. Follow the chain without losing the outer messages. The deepest cause is the lowest recorded failure, but the actionable defect may be invalid application input, configuration, or a bad retry higher in the chain.
Suppressed: is different. Try-with-resources can preserve a close failure as suppressed while another exception remains primary. Check both structures during a complex resource failure.
Common Mistakes & Pitfalls
- Reading only the wrapper: it may omit the low-level detail.
- Reading only the deepest cause: it may omit the operation and input context.
- Dropping the cause:
new Wrapper(message)loses the original frames. - Wrapping without new context: repeated generic wrappers add noise.
- Confusing
Suppressed:withCaused by:: they represent different relationships.
Check your understanding
Answer these without looking back at the article.
- How do you read a Java stack trace to find the source of an error?
- How do you read a NullPointerException stack trace in Java?
- What does a StackOverflowError stack trace look like and what causes it?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.