On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library
precondition violations in particular from exceptions (or
error codes) to contracts. The programming world now broadly
recognizes that programming bugs (e.g., out-of-bounds access,
null dereference, and in general all
pre/post/assert-condition violations) cause a corrupted state
that cannot be recovered from programmatically, and so they
should never be reported to the calling code as exceptions or
error codes that code could somehow handle.
So, I have finally convinced the C++ world about that! Now if I
can only convince the D world :-)
But that's not how D works. It throws an Error which can be
caught.
If people are allowed to do something they assume it's legitimate.
It should be a compile time error to catch an Error, but it
doesn't even emit a warning and it seems to work well which is
probably proof enough for people to assume it's good.
In my opinion it shouldn't throw an error but abort at once after
printing the stack trace. Which would have the nice side effect
of stopping almost exactly on the line in a debugger.
An out of bounds range error for instance prints the assertion
message and then gracefully exits (exit code is 1, which
indicates a code that can be handled by the calling process,
rather than a return code of -6 for abnormal termination).
Also there is, or at least was a few months ago, that gotcha in
concurrency that when a thread throws an Error it goes silent,
the thread simple gone.
The only way I could finally get to the root of the cause was to
catch everything in that thread.
Aborting would be preferable so the debugger can catch such
things. Makes it a matter of rerunning the program instead of
hours of bug hunting and guess work.
Also in spite of the above, a bug in a thread should probably
bring down the whole program since if a thread is in
unrecoverable, corrupt state, it follows that the entire program
is in corrupt state.
