What should happen when the assert message expression throws?

[Ali Çehreli]

On 11/25/22 08:48, kdevel wrote:

 > I would like to know if there is a representation of that ominous
 > "invalid state" in terms of bits and bytes. Well, it doesn't have to.
 > But if we are talking about "invalid state" we should be able to explain
 > what we mean when we use that group of words. I don't use the term
 > because I do not intuitively know what it means and the D docs do not
 > define the term either.

I think it is definition and comes from convention:

- Errors represent situations where the program should not continue

- AssertError is an Error, which is thrown when an assert condition fails

For that reason, assert conditions do include checks that define the 
valid state of a program.

The same condition can be used for throwing an Error or an Exception:

   exists(configFile)

Only the programmer knows which one makes sense:

- If configFile was a string input by the user, then the following is 
appropriate:

   enforce(exists(configFile), /* ... */)

- If configFile was a string representing a file e.g. that has just been 
generated by the same program, then the following is appropriate:

   assert(exists(configFile), /* ... */)

Only the programmer knows.

 > The condition is false. That is what I want to discuss. My question is:
 > What does that mean? Does it mean more than writing a comment
 >
 >     // I solemnly swear a is zero.

Your example code is interesting because it expects 'a == 0' right after 
initializing it with 1. However, since that AssertError is caught 
(against convention), there is no observable remnant of that AssertError 
in the program. Since it did not represent a valid state anyway, no harm 
done there. Humans are fallible, so we expect cases where assert 
conditions do not represent a valid program state. We can discount those 
cases.

Having said that, that assert means this to me: "For this program to be 
able continue, the value of 'a' must be 0."

 > In your last post you wrote "If that assertion fails, the program is in
 > an invalid state." The assertion in my program fails. According to the
 > common inference rules the program must be in an invalid state

I trust the programmer makes mistakes. :) I don't think that is a 
correct assert condition.

 > and
 > according to your last statement this invalid state is only exposed,
 > i.e. the program was already in "invalid state" before the assert 
statment.

I strongly think so. An assertion failure is a late discovery of a problem.

 > Thus my question: What constitutes the invalid state in my example
 > program? The program is syntactically valid, no UB, nothing else.
 >
 >> The invalid state may have been reached long ago.
 >
 > In my fabricated example program: Where and by what event went the
 > program into "invalid state"?

I am repeating myself but I think your program has a programmer error in 
that condition. Swallowing the thrown AssertError is interesting but I 
don't think that program has any invalid state.

The way I see it, valid state is defined by the collection of assertion 
checks, which may be incorrect themselves or conflict with each other. 
Hopefully, the programmer catches and corrects mistakes in the checks 
and approaches a more correct definition of the valid state of that program.

Ali