Assertions in production code on Reddit

[Nick Sabalausky (Abscissa)]

On 08/30/2018 05:31 PM, Walter Bright wrote:
>> https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ 
>> 
 >
 >High reliability is not achieved by making perfect designs, it is 
 >achieved by making designs that are tolerant of failure. Runtime 
 >checking is essential to this, as when a fault is detected the program 
 >can go into a controlled state doing things like:
 >
 >    aborting before more harm is done
 >    alerting the user that the results are not reliable
 >    saving any work in process
 >    engaging any backup system
 >    restarting the system from a known good state
 >    going into a 'safe mode' to await further instructions
 >

I'm totally all for all of this in principle.

But here's the problem:

Aside from "abort the process immediately once...uhh, once the faulty 
process itself has already successfully *detected itself to be faulty*" 
(ie, already a violation of the basic principles being promoted in the 
article), we don't actually HAVE ready-to-use facilities for any of this.

Since we don't actually have such facilities, getting people to actually 
code by them IS going to be an even bigger uphill battle than trying to 
get them to unittest without any ready-to-use unittesting facilities.

And then THAT leads to yet another problem: If they're not actually 
coding by those principles (which they're obviously not doing because 
the facilities to do so aren't there), then they ARE occasionally going 
to be needing *some* code to be run after the fault occurs:

For example:
- Evaluating the assert condition to even detect something went wrong at 
all.
- Generating the assert failure reporting string.
- Generating the stack trace.
- Sending the failure string and stack trace to the logging process. Oh 
wait, we don't have an external logging process facility...
- Directly reporting and logging and the failure string and stack trace.

(And that list still ignores any cleanup the OS can't/doesn't know to do 
on our behalf.)

And, shit, if it's even POSSIBLE to do any of that within "the process 
that's already in an undefined state", then clearly we already have 
enough successful intra-process compartmentalization that the "At this 
point, we can't rely on ANYTHING!!!" notion is demonstrably bogus anyway.

Don't get me wrong, I'd LOVE to be able to do things as you suggest: To 
have all my fault-handling functionality and STILL have zero-reliance on 
the faulty process. But we DON'T have those facilities, therefore, 
nobody outside aeronautics, pacemaker firmware, etc, is realistically 
going to be able to justify going to all bother of creating such 
facilities to go along with their website, or text editor, or 
number-crunching tool, or videogame, etc... (IF the programmer in 
question even has the expertise to implement such a system correctly 
anyway - and most don't).