Что касается устойчивости программы ко вводу и оперированию данными, имеющими небесконечную область определения (имено так, а не какие-то "помехи" от пользователей), то я не собираюсь спорить с тем, что обычно нужно закладывать соответствующие проверки. Но не всегда. Как пример, можете посмотреть на описание разницы дебаг- и релиз- компиляции embOS. Я не собираюсь спорить, что при работе программы могут возникать ошибки, но эти ошибки можно ранжировать как по природе их возникновения, так и к какой области работы устройства они относятся (системные ошибки или ошибки на уровне приложения), так и по степени их значимости в способе определения степени работоспособности устройства и/или программы, степени достоверности выходных данных и пр. Приложение, IMNHO, не должно бороться с системными ошибками, независимо от их природы - оно должно уметь работать в определённых условиях. И если, как Вы привели пример, системная функция(!) не смогла выделить память или сообщила, что файл не доступен, то программа должна действовать в зависимости от начальных требований - например, может зависнуть на открытии файла, выдавая в stderr сообщения об ошибке, может попытаться открыть другой файл и т.п. Если действия в случаях наличия информации об ошибках при взаимодействии с системными средствами не определены при согласовании задания или не уточнены при написании приложения, то вопрос, конечно, в первую очередь к программисту. Вот только к разрушению данных в условия неких "помех" никакого отношения не имеет. Изложенные на Сахаре методы имеют право на жизнь, только не в том контексте, в котором их связал автор. А по самим методам я пока не спорю, а просто говорю, что все описанные методы известны (фактически классика), вот только все они по классике чуть не такие и точно не для того применяются.