Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....

[wjoe]

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.