Java also has chained exceptions, done manually

Andrei Alexandrescu SeeWebsiteForEmail at erdani.com
Thu Sep 6 14:39:12 UTC 2018


In an earlier post, Don Clugston wrote:

> When I originally implemented this, I discovered that the idea of
> "chained exceptions" was hopeless naive. The idea was that while
> processing one exception, if you encounter a second one, and you
> chain them together. Then you get a third, fourth, etc.
> 
> The problem is that it's much more complicated than that. Each of the
> exceptions can be a chain of exceptions themselves. This means that
> you don't end up with a chain of exceptions, but rather a tree of
> exceptions. That's why there are those really nasty test cases in the
> test suite.
> 
> The examples in the test suite are very difficult to understand if
> you expect it to be a simple chain!
> 
> On the one hand, I was very proud that I was able to work out the
> barely-documented behaviour of Windows SEH, and it was really
> thorough. In the initial implementation, all the complexity was
> covered. It wasn't the bugfix-driven-development which dmd usually
> operates under <g>.
> 
> But on the other hand, once you can see all of the complexity,
> exception chaining becomes much less convincing as a concept. Sure,
> the full exception tree is available in the final exception which you
> catch. But, is it of any use? I doubt it very much. It's pretty
> clearly a nett loss to the language, it increases complexity with
> negligible benefit. Fortunately in this case, the cost isn't really
> high.

First off, there's no tree of exceptions simply because... well it's not 
there. There is on field "next", not two fields "left" and "right". It's 
a linear list, not a tree. During construction there might be the 
situation whereby two lists need to be merged. But they will be merged 
by necessity into a singly-linked list, not a tree, because we have no 
structural representation of a tree. (As an aside, it does seem we could 
allow some weird cases where people rethrow some exception down the 
chain, thus creating loops. Hopefully that's handled properly.)

Second, it does pay to keep abreast other languages. I had no idea (and 
am quite ashamed of it) that Java also has chained exceptions:

https://www.geeksforgeeks.org/chained-exceptions-java/

They implement them manually, i.e. the user who throws a new exception 
would need to pass the existing exception (or exception chain) as an 
argument to the new exception's constructor. Otherwise, an exception 
thrown from a catch/finally block obliterates the existing exception and 
replaces it with the new one:

https://stackoverflow.com/questions/3779285/exception-thrown-in-catch-and-finally-clause

So chaining exceptions in Java is a nice complementary mechanism to 
compensate for that loss in information: when you throw, you have the 
chance to chain the current exception so it doesn't get ignored. Because 
of that, D's chained exceptions mechanism can be seen as an automated 
way of doing "the right thing" in Java.

We should study similarities and distinctions with Java's mechanism and 
discuss them in our documentation.


Andrei


More information about the Digitalmars-d mailing list