What should happen when the assert message expression throws?
Ali Çehreli
acehreli at yahoo.com
Thu Dec 8 18:05:13 UTC 2022
On 12/8/22 08:22, Dukc wrote:
>> Add to the above another observation which I had after Patrick
>> Schluter's message: Even the execution of the assert check is
>> best-effort because if the check will fail, the program has been in
>> invalid state for an unknow amount of time anyway.
>
> I disagree slightly. Yes, the higher level purpose the assertion is
> accomplishing is best-effort - that is, shutting down a program
> overtaken by a bug. But I think the implementation itself should not be
> so. If we assert that x is 5, catching x being 4 must happen every
> single time, not on best effort basis, unless the assertion is disabled
> by a compiler switch.
The program may be affected by undefined behavior, which may cause x to
have any value.
I used "hopeful" and then "best-effort" but a better phrase might have
been "wishful": A program is trying to catch itself in good (or bad)
state by executing some code, code usually related to the bad state that
is about to be caught:
assert(o.foo == o.bar * 2);
foo and bar may be member functions of an object in bad state. It is
wishful thinking because I am using the same object to catch its bad state.
Let's say I am happy I caught the program in bad state and am happy to
about to abort the program: That's only happy thinking because I should
have aborted when the invariant was broken in the first place, not when
I haphazardly realized at a later time. What damage has already been
done? If I am happy I am aborting, am I sadder I am aborting only now,
some time later than that unknown time when the invariant was broken?
I got into this theoretical discussion but I don't feel well equipped.
Maybe we use assert to catch both logic errors as well as hardware
issues. Perhaps we need to classify error categories better first. I
don't know enough.
Ali
More information about the Digitalmars-d
mailing list