| |
 | Posted by Nick Sabalausky (Abscissa)
in reply to Walter Bright |  Permalink Reply |
|
Nick Sabalausky (Abscissa) 
Posted in reply to Walter Bright
| 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).
|
