Java also has chained exceptions, done manually

[Don]

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.