D is dead

[Don]

On Monday, 27 August 2018 at 07:34:37 UTC, Walter Bright wrote:
> On 8/23/2018 8:53 PM, David Nadlinger wrote:
>> On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright 
>> wrote:
>>> D deals with it via "chained exceptions", which is 
>>> terrifyingly difficult to understand. If you believe it is 
>>> understandable, just try to understand the various devious 
>>> test cases in the test suite.
>> 
>> I don't think that assessment is accurate. Yes, I ported EH to 
>> a few new targets and wrote the first correct implementation 
>> of exception chaining for LDC, so I'm probably a couple of 
>> standard deviations off the average D user in that regard. But 
>> said average D user doesn't care about most of the nuances of 
>> this problem, like the details of implementing exception 
>> chaining without allocating too much,
>
> I find myself unable to explain the rationale of the behavior 
> exhibited by the current chaining system. I dared not change 
> it, as I presumed somebody surely built a store around it. It 
> does not simply chain exceptions.
>
>
>> or which exceptions take precedence in various intentionally 
>> twisted test cases.
>
> The only documentation for this is the test suite itself, which 
> does not have any documentation or rationale either, just tests.
>
> I would appreciate it if you did document what it's supposed to 
> do and why, as likely nobody else knows. Maybe if I understood 
> why I'd be more forgiving of it :-)
>
>
>> What they do care about is that the fact that an error has 
>> occurred is propagated sensibly in all cases without requiring 
>> extra attention, and that information as to the origin is not 
>> lost (hence chaining rather than just replacement). Heck, the 
>> fact that we still don't have default backtrace handlers that 
>> consistently work on all platforms is probably a much bigger 
>> problem than the minutiae of exception chaining behaviour.
>
> I wish the minutiae was documented somewhere :-( as I care 
> about the nuances of it, if only because I'm ultimately 
> responsible for keeping it working correctly.


I can explain this, since I did the original implementation.
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.

-Don.