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
