On Thursday, 6 September 2018 at 14:39:12 UTC, Andrei
Alexandrescu wrote:
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.
That's correct, the *end result* is not a tree of exceptions, but
the intermediate state is a tree. There can be an arbitrary
number of exceptions in flight at any given time.
The final exception chain is the result of a depth-first traverse
of the call stack.
Given an exception chain A->B->C, you don't know if C was thrown
while processing B, or while processing A.
So the exception chain is inherently ambiguous. My point is that
this reduces the appeal of the feature.
Note that my message was in response to Walter being confused as
to why the tests were so complicated.
(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.)
A loop is not possible in ordinary operation, any more than a
loop is possible in a depth-first traverse of a tree. But, what I
don't know is, what happens if there is a switch to a different
fiber inside a `finally` clause?
I never considered that.
At Sociomantic we have code to deal with exceptions being thrown
across context switches. Normally it's a bad idea. However, I
don't believe we considered that the exception being thrown
across the context switch, might not be the only exception in
flight at that moment.
Maybe it's perfectly fine. I just don't know.
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/
This is fascinating.
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
It's implemented, it works, I was quite proud of having figured
it out. Is it actually useful? Dunno.
Don.
