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