Игнорирование (серьезных) ошибок поддержать программу?

Я использовал метод обработки ошибок «военная топология».

Ошибки следует классифицировать по степени серьезности, а затем либо обрабатывать, либо передавать вышестоящему руководителю для устранения.

Рядовому приказали очистить плац зубной щеткой. У него заканчивается мыло. Это проблема, которую он должен решить сам, а не беспокоить своего начальника.

Если на плацу высадился взвод вражеских солдат, ему, вероятно, следует рассказать об этом своему начальству.

Пожалуйста, отметьте меня в разделе «snark» вашей книги, когда вы богаты и знамениты.

Для продолжения работы вашей программы вам необходимо иметь базовое состояние, которое, как вы знаете, является хорошим, а затем каждый запрос обрабатывается независимо. Например:

• Клиент-серверное приложение. Каждый новый запрос, поступающий на сервер, обрабатывается независимо, и если один запрос катастрофически терпит неудачу, сервер перехватывает его и либо делает вид, что этого не произошло, либо сообщает клиенту, что он потерпел неудачу.
• Локальное приложение. Есть некоторая базовая форма, и все, что пытается сделать пользователь, создается оттуда. Если процесс завершается катастрофическим отказом, экземпляр этого процесса (возможно, форма MDI) уничтожается, и пользователю остается исходная форма оболочки приложения, и он может попробовать еще раз или сделать что-нибудь еще.

Самое главное, о чем нужно быть осторожным, если вы это делаете, - это то, что ваше приложение должно иметь какое-то неснижаемое ядро, которое не содержит ошибок и будет обрабатывать любые незапланированные исключения (непростая задача). Не говоря уже о том, что проглатывание неожиданных исключений может сделать устранение неполадок / отладку невыносимым, неснижаемое ядро ​​не может выйти из строя, иначе выйдет из строя все приложение.

Не знаю насчет имени.

Насколько это плохо? Я не знаю; для чего ты это используешь? Обычно лучше иметь сбой, чем тихую ошибку. Сбои очевидны и обычно могут быть исправлены, но скрытые ошибки, скорее всего, останутся незамеченными, поэтому не имеет значения, насколько легко их исправить.

Есть ситуации, в которых это может быть правильным поступком. Я читал о компьютере управления огнем ВМФ с «боевыми панелями», который отключал средства исключения на том основании, что пока он работал, он мог выдавать хорошую информацию, а если он не работает, вы очень хорошо знаете это не так. В бою часто бывает так, что ничего не делать плохо, даже если вы не можете сделать что-то особенно полезное.

Вы предполагаете, что можно определить, что все ошибки типа X являются ограничителями показа, а все ошибки типа Y - нет. Я думаю, что это звучит хорошо на первый взгляд, но дьявол кроется в деталях. На практике я не думаю, что можно придумать хоть одну ошибку, которая всегда безобидна.

Вы упоминаете «Синтаксис, имя, тип». Если вам известны общие синтаксические ошибки, которые можно объективно исправить, не вызывая проблем, включите их в спецификацию и позвольте компилятору обработать их (после этого они больше не будут синтаксическими ошибками).Я не знаю, к чему относится «Имя». Чтобы избежать ошибок типа, нужно иметь систему динамической типизации. Опять же, это часть спецификации, а не обработка ошибок.

Я читаю, что вы хотите иметь определенную спецификацию, универсальный компилятор, позволяющий писать синтаксис различными способами, и систему динамической типизации. Это здорово, и я желаю вам удачи. Но не путайте это с интерпретацией намерений кодировщика и мыслью, что вы можете отличить нормальную ошибку от вредной.

Мне кажется, вы говорите о разнице между правильностью и робастностью . Очень надежная программа продолжает работать, несмотря ни на что. Очень правильная программа дает только правильные результаты. Эти два качества часто диаметрально противоположны и должны уравновешиваться друг с другом. Нет общего способа найти баланс между ними. Это зависит от цели программы. Таким образом, у компилятора действительно нет возможности разумно решить, что ему следует отдать предпочтение.

Программирование на устойчивость - не обязательно плохо. Например, драйверы устройств обычно очень надежны (по крайней мере, хорошие). Вообще говоря, это не нормально, когда драйвер устройства взрывается перед лицом неожиданных ошибок, поскольку это может привести к сбою всей системы. Драйверы устройств часто интерпретируют «фатальные» ошибки так, как вы описываете: «Мне все равно». Например, если оборудование отправляет поврежденные данные, часто бывает достаточно просто удалить их и дождаться новой выборки.