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

On Thursday, 6 September 2018 at 14:39:12 UTC, Andrei Alexandrescu wrote:
> 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.

The runtime appends any exception raised by a `scope (exit|failure)` statement to the next list of an exception already being raised. So if I write:

scope (exit) throw new Exception("scope 1");
scope (exit) throw new Exception("scope 2");
throw new Exception("primary");

I get output like:

object.Exception@scratch.d(21): primary
----------------
??:? void scratch.throwy() [0x53a74c01]
??:? _Dmain [0x53a74d68]
object.Exception@scratch.d(26): scope 2
----------------
??:? void scratch.throwy() [0x53a74ce1]
??:? _Dmain [0x53a74d68]
object.Exception@scratch.d(25): scope 1
----------------
??:? void scratch.throwy() [0x53a74d42]
??:? _Dmain [0x53a74d68]

Okay, that seems reasonable. But what if each of those `scope(exit)` statements had their own chains?

scope (exit) throw new Exception("scope 1", new Exception("cause 1"));
scope (exit) throw new Exception("scope 2", new Exception("cause 2"));
throw new Exception("primary");

object.Exception@scratch.d(8): primary
----------------
??:? void scratch.throwy() [0x7259caf3]
??:? _Dmain [0x7259cc64]
object.Exception@scratch.d(7): scope 2
----------------
??:? void scratch.throwy() [0x7259cba5]
??:? _Dmain [0x7259cc64]
object.Exception@scratch.d(7): cause 2
object.Exception@scratch.d(6): scope 1
----------------
??:? void scratch.throwy() [0x7259cc4c]
??:? _Dmain [0x7259cc64]
object.Exception@scratch.d(6): cause 1

The actual structure of the exceptions: `primary` has children `scope 2` and `scope 1`; `scope 2` has child `cause 2`; `scope 1` has child `cause 1`. A tree.

The encoded structure: a linked list where only the first two positions have any structure-related meaning and the rest are just a sort of mish-mash.

This isn't a situation you get in Java because Java doesn't have a way to enqueue multiple independent actions at the end of the same block. You just have try/finally and try(closeable).

> (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.)

Not if you semi-manually create the loop:

auto e = new Exception("root");
scope (exit) throw new Exception("scope 1", e);
throw e;

Filed as https://issues.dlang.org/show_bug.cgi?id=19231

On 9/6/18 1:13 PM, Neia Neutuladh wrote:
> The actual structure of the exceptions: `primary` has children `scope 2` and `scope 1`; `scope 2` has child `cause 2`; `scope 1` has child `cause 1`. A tree.

No, it's a list.

> The encoded structure: a linked list where only the first two positions have any structure-related meaning and the rest are just a sort of mish-mash.
> 
> This isn't a situation you get in Java because Java doesn't have a way to enqueue multiple independent actions at the end of the same block. You just have try/finally and try(closeable).
> 
>> (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.)
> 
> Not if you semi-manually create the loop:
> 
> auto e = new Exception("root");
> scope (exit) throw new Exception("scope 1", e);
> throw e;
> 
> Filed as https://issues.dlang.org/show_bug.cgi?id=19231

Thanks!


Andrei

On Thursday, 6 September 2018 at 23:34:20 UTC, Andrei Alexandrescu wrote:
> On 9/6/18 1:13 PM, Neia Neutuladh wrote:
>> The actual structure of the exceptions: `primary` has children `scope 2` and `scope 1`; `scope 2` has child `cause 2`; `scope 1` has child `cause 1`. A tree.
>
> No, it's a list.

What relationship is supposed to be encoded in Throwable.next?

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.

On 07/09/18 09:42, Don wrote:
> 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.

Each fiber maintains its own EH context. In theory (and I will not claim that I actually understand how this construct works), if you switch to a different fiber, you'll be out of the EH handling code until you switch back.

It caused quite a bit of headache for Mecca, as we do not switch fibers using the DRuntime mechanism. At the moment, Mecca just copies internal DRuntime implementation details while keeping our fingers tightly crossed that nothing gets borken.

I have, fairly high on my to-do list, a task to submit a PR to DRuntime to properly export this interface, thus removing access to private members from Mecca. Such a change would also allow DRuntime to implement the Fiber class somewhere other than core.thread.

Shachar

I think he means colliding exceptions, not chained, their use cases are not identical. You can have chaining in any language, but it doesn't necessarily happen on collision.

On Thursday, 6 September 2018 at 14:39:12 UTC, Andrei Alexandrescu wrote:
> 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/

Now I'm surprised... is there a language (except C++) that supports exceptions that does _not_ have it?
Java: getCause()
C#: InnerException
PHP: getPrevious()
...

> 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.

I think chained exception in D is semantically very different from other languages like Java.

In languages like Java or C# the exception chain has nothing to do with saving exceptions that are thrown in finally blocks.
Instead the chain is used for a layer model. The "outer" exception is the higher level exception and the "inner" exception is the lower level cause of the higher level exception.

Often a low level exception is quite meaningless when thrown over multiple levels in the call stack.
For example, imagine a program that uses a configuration file. While parsing the configuration, a misformatted number is encountered.
If the NumberFormatException is propagated to the top level, it is basically useless for programmatic error handling.
This is much better:
ConfigurationException -> JsonParsingException -> NumberFormatException

The higher level exceptions are therefore directly caused by the lower level exception and always thrown _directly_ in the catch block where the lower level exception is catched and readily available. Not in a finally block and not indirectly in a function called from the catch block.
Manually passing the inner exception to the constructor of the outer exception is trivial and IMO the right thing, because it's probably not always wanted.

Now in D, chained exceptions work differently.
The first exception that is thrown is deemed the "important" exception and later exceptions are simply chained to it. A direct semantic connection between the exceptions is not possible at all, since the later exception has no knowledge about the first exception at all.
It also means that the order of the exceptions is reversed. The first exception is the "outer" exception which is the exact opposite of how it is meant in Java.

When handling an exception, it's not clear at all what those additional exceptions mean and how they should be handled.

Personally I find the Java/C# model much more useful.

---
Tobias

On 9/7/18 7:15 PM, Tobias Mueller wrote:
> On Thursday, 6 September 2018 at 14:39:12 UTC, Andrei Alexandrescu wrote:
>> 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/
> 
> Now I'm surprised... is there a language (except C++) that supports exceptions that does _not_ have it?
> Java: getCause()
> C#: InnerException
> PHP: getPrevious()
> ...

David Nadlinger wrote that Python also has them.

> I think chained exception in D is semantically very different from other languages like Java.
> 
> In languages like Java or C# the exception chain has nothing to do with saving exceptions that are thrown in finally blocks.
> Instead the chain is used for a layer model. The "outer" exception is the higher level exception and the "inner" exception is the lower level cause of the higher level exception.
> 
> Often a low level exception is quite meaningless when thrown over multiple levels in the call stack.
> For example, imagine a program that uses a configuration file. While parsing the configuration, a misformatted number is encountered.
> If the NumberFormatException is propagated to the top level, it is basically useless for programmatic error handling.
> This is much better:
> ConfigurationException -> JsonParsingException -> NumberFormatException
> 
> The higher level exceptions are therefore directly caused by the lower level exception and always thrown _directly_ in the catch block where the lower level exception is catched and readily available. Not in a finally block and not indirectly in a function called from the catch block.
> Manually passing the inner exception to the constructor of the outer exception is trivial and IMO the right thing, because it's probably not always wanted.
> 
> Now in D, chained exceptions work differently.
> The first exception that is thrown is deemed the "important" exception and later exceptions are simply chained to it. A direct semantic connection between the exceptions is not possible at all, since the later exception has no knowledge about the first exception at all.
> It also means that the order of the exceptions is reversed. The first exception is the "outer" exception which is the exact opposite of how it is meant in Java.
> 
> When handling an exception, it's not clear at all what those additional exceptions mean and how they should be handled.
> 
> Personally I find the Java/C# model much more useful.

Well indeed the upper you are on the stack, the more likely you are in a high-level function. It's a good heuristic. Sadly we cannot change chaining semantics now, but it does stand to reason to print the last exception in a chain, instead of the head, as the most relevant cause. Guess we'd do good to have such functionality in the stdlib.


Andrei

On Sunday, 9 September 2018 at 01:09:24 UTC, Andrei Alexandrescu wrote:
> it does stand to reason to print the last exception in a chain, instead of the head, as the most relevant cause. Guess we'd do good to have such functionality in the stdlib.

So given code like:

  scope (exit) throw new Exception("cleanup failed");
  throw new Exception("main operation failed");

You would prefer that this show the "cleanup failed" exception more prominently than the "main operation failed" exception?