On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
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.
Ah, that's a really nice statement.
So, I have finally convinced the C++ world about that! Now if I
can only convince the D world :-)
Oh, I'm convinced.
At work here I have emerged from a long, dark, debate on the
subject within the team.
The ultimately solution was to realize there are actually TWO
facilities with TWO entirely different purposes that have been
overloaded with the same name.
Alas, the word "assert" now is inextricably mired in this
confusion.
Half our team used asserts to mean "This mustn't _ever_ happen in
unit tests (unless we set up a specific test case for that), and
it will never happen if the incoming signal is standards
compliant, but it may happen (due to RF noise, and/or competitor
violating the standard and/or adding in proprietary stuff into
the data and/or we're being attacked) so we _must_ fall through
the assert at run time, and handle that case somehow, but
preferably make a note that something unexpected happened."
The other half of the team meant, "If the expression is false, it
means the code on this line or on the execution path prior to it
is definitely defective and must be fixed immediately.
And there is absolutely no hope the code after it will work, and
continuing on will make the system flaky and unreliable, and the
only path back to reliable function is a reset.
All code after this line may explicitly assume, and depend on, the
expression being true.
Any attempt to handle the possibility of the expression is false
is buggy, useless and probably will be removed by the optimizer.
Any urge to handle the possibility of the expression being false
after the assert, should be replaced by the inclination to review
the code on the execution path prior to the assert, to ensure
that the expression will always be true."
Alas, both sides were using the same word "assert" to mean these
different things, resulting in conversations that went around and
around in meaningless circles.
We have resolved the debate by identifying these two different
meanings, and given the facilities implementing them two
different names and documenting the difference in meaning and
intent.
