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.
