| |
 | Posted by Ali Çehreli
in reply to kdevel |  Permalink Reply |
|
Ali Çehreli 
Posted in reply to kdevel
| 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
|
