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

Question

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

• Есть ли у этой "парадигмы" имя? Я имею в виду ожидать
• Насколько плохо это делать?
• Существуют ли используемые программы, которые просто следуют: « Эй, это фатальная, неожиданная ошибка - но вы знаете, что? Мне все равно!» ?

Answer 1

По именованию можно сказать, что язык демонстрирует "головокружение".

Сбои обычно предпочтительнее, потому что программы не должны возвращать непредсказуемые и неповторимые результаты. Как правило, нет результата лучше ненадежного, особенно если вы занимаетесь чем-то критичным. Например, лучше, чтобы заказ клиента на Amazon не обрабатывался (они всегда могут повторно отправить его), чем для того, чтобы клиенту доставили случайный продукт. Некоторые ошибки действительно невозможно исправить, например, если указатель инструкции поврежден.

Вы можете реализовать подобное поведение в большинстве современных языков с обработчиками catch всех исключений.

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

Я не знаю имени.

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

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