The lower-level exception (the cause) is passed to the higher-level exception, which provides an accessor method (Throwable’s getCause method) to retrieve the lower-level exception:
It's worth adding a warning here (in line with my previous note): You shouldn't use exceptions extracted from 'cause' for your code's behavior. You may not be able to count on the layer that that execution came from changing it even being swapped out.
I have had to violate this, as it was the only way to get the detail I needed of the underlying cause in order to present the user with the most appropriate UI. And I knew it made my code more fragile (but that it was worth it, in part because I had a fallback in place — in case the underlying implementation changed — where the UI would gracefully degrade).
Thar reinforces another lesson here: your exception should provide explicit programmatic information about the cause (so the consumer didn't have to actually consult the cause) if it may be important for the application logic (i.e., not just to help the developer with debugging).
