What should happen when the assert message expression throws?

[Ali Çehreli]

On 11/27/22 14:35, kdevel wrote:

 >> I think it is definition and comes from convention:
 >>
 >> - Errors represent situations where the program should not continue

I still agree with myself there: Errors should be used (trivially with 
assert) to specify the cases where the program cannot continue.

 > If the programmer who implements a function/method is not the author of
 > `main` he most certainly is not in charge of deciding on the fate of the
 > running program.

That's agreeable. Error represents aborting mission but there are 
safety-critical applications where continuing with sane steps is better 
than aborting mission. One example given is autonomous-driving software 
aborting driving because of a thrown Error. It should not happen. The 
software should decide to drive slowly to the side.

See... Even that's wishful thinking. When an assertion fails, we don't 
know whether the execution of that slowly driving to the side will do 
that. The absurd state we caught ourselves in may be due to a hardware 
issue where steering to the right may skid the vehicle out of control.

For that reason, perhaps the software still aborts but another unit 
takes over.

Sure... but these are outside of a program deciding to abort mission:

   int[] arr;
   populateArrar(arr);
   assert(arr.length > 7);

What should the program do? Attempt to add arbitrary items to the array? 
What if that fails as well? If it could work, then it should not be 
assert in that last line, rather the following:

   if (arr.length <= 7) {
       log(/* ... */);
   }
   // continue

 > For me, it
 > makes no difference if the file name is user input, taken from the
 > command line, or hardcoded into the program. Well, actually I would not
 > code such a check at all. I would let the open function throw the
 > exception (also to avoid TOCTTOU).

I may do that as well. However, the following does not strike me as 
wrong at all:

     createConfigFile("foo");
     assert(exists("foo"));

Even though another actor in the system may delete the file after the 
check, it is also conceivable that a newly-created file should exist.

 > The decision if the program can continue without configuration file is
 > probably taken in `main` or in the consumer of that configuration data:
 > If there is a default configuration dataset the program might continue.

I was imagining the file that should exist as the default configuration.

I wonder whether my example is wrong or whether it is always conceivable 
that all assert checks can be removed.

 >> Having said that, that assert means this to me: "For this program to
 >> be able continue, the value of 'a' must be 0."
 >
 > In order not to convey that meaning in real programms I only use asserts
 > in unittests.

That's the approach some safety-critical software takes: asserts exist 
only in test phase. There should be no assert left in the final product. 
All assertion failures should be caught during development phase.

 >> The way I see it, valid state is defined by the collection of
 >> assertion checks,
 >
 > But sometimes you don't believe what the code says. If it does not match
 > up with your presuppositions you testify validity though the assert
 > checks fail. But then isn't that invalid state a non-local or even a
 > subjective thing?

I don't understand. But the way I see it, yes, invalid state is 
completely subjective. The programmer defines it with assert checks and 
the program ensures it stays in that state.

Ali