&gt; The easiest way to be sure a code path will run properly is to avoid writing it in the first place.<p>Agreed.  So the app shouldn&#x27;t contain anything extra not related to it&#x27;s primary function.<p>However, handling error conditions reported by the operating trumps the extraneous code rule.  But there are many ways to handle an error, including ignoring it if that&#x27;s the proper thing to do.<p>Crashing is never the proper thing to do.  If the program had simply exited at the very minimum, a restart would have taken a lot less time than a complete reboot of the machine.  The software crashed that badly that it required a reboot of the machine.<p>&gt; Why is nobody questioning the propriety of using an off-the-shelf Windows PC in safety-of-life applications?<p>They are, in the other threads.  But using a better OS for the task wouldn&#x27;t prevent the coding error the programmer did.<p>Let&#x27;s say they chose Linux.  A signal goes off or something else happens and their read call fails.  Since they expect all their I&#x2F;O to succeed they crash just like the Windows box.<p>If they bothered to handle the error and check for EINTR they&#x27;d know it was interrupted and not a hardware failure.<p>My point is, changing operating systems doesn&#x27;t protect you from poorly coded applications.