Software shouldn&#x27;t necessarily try to account for errors in that manner.  Usually, the most graceful thing to do is to exit cleanly.<p>For example, if there is a massive amount of data, it has to be stored on disk.  It&#x27;s too large to keep in memory.  And if the point of the program is to transform that data in real time, then it has to have access to the disk.<p>The antivirus basically unplugged the disk.  What can it do to recover?  There&#x27;s nothing to be done.<p>It should be able to survive that situation, of course.  When the disk is plugged back in, it should be able to restart without any problems.  But I think that&#x27;s a different kind of resiliency than what you&#x27;re referring to.<p>In this case, the only way to recover would be to copy the frozen data to a new area of the hard drive, assuming it retained read access.  But such complexities result in brittle implementations, prone to acquiring bugs.  What if the disk space runs out?  So you check beforehand whether there&#x27;s enough space.  But what if some other program starts consuming disk space in the middle of your copy operation?  And so on.  It&#x27;s an endless spiral of design complexity.<p>The situation in the article seems closer to hardware failure than a design oversight.