8 ms·
java has the "rootCause" constructor which wraps another Exception (actually Throwable) of any type passed in. so the idiomatic way would be to create your own
by paulmd 2y ago
java has the "rootCause" constructor which wraps another Exception (actually Throwable) of any type passed in. so the idiomatic way would be to create your own error types, but to pass the lower-level exception in as the rootCause so you can trace the exceptions down the stack if desired. Since the type is Throwable rather than a dependency-specific exception, this isn't exposed in the interface unless you go out of your way to cast things in an obviously dangerous way.
Does that not exist in Rust?
- Dylan16807 2y agoWhen you say "obviously dangerous" do you mean "obviously breaking encapsulation" or is there a bigger issue? If there's a bigger issue then I'm not sure how it's useful for solving this problem of wanting the details.
- paulmd 2y ago"obviously breaking encapsulation", like if you pull some interface from the dependency through yours, then yeah, you're broken when they break things. That's a generalized interface problem and java can't help you anymore than rust can. But I guess it's true that it may not be obvious that library interfaces may churn unexpectedly etc, you are dependent on the good behavior of others unless you specifically take steps to abstract it. (although you do absolutely have to be careful about what you are returning in a client-facing error message etc. don't return the parts of the stack trace that leak information about your application to an actual client, they should be caught by your framework and turned into generic "4xx git rekt"/"5xx we made a fucky wucky" messages that don't reveal too much about your environment.) not a java problem specifically for either of those, it just seems odd coming from that world that there's not a concept of a "recursive exception stack" like that in rust?