Концепции программирования: что делать при возникновении исключения?

Question

Это на самом деле не относится ни к какому конкретному языку, но если это имеет значение, я использую VB.NET в Visual Studio 2008.

Кажется, я не могу найти что-то действительно полезное в Google по этой теме, но мне было интересно, что является обычной практикой, когда генерируется и перехватывается исключение, но поскольку оно было сгенерировано, приложение не может продолжать работать.

Например, у меня есть исключения, которые выдает мой класс FileLoader , когда файл не может быть найден или файл считается поврежденным. Исключение выдается только внутри класса и на самом деле не обрабатывается. Если ошибка обнаружена, то генерируется исключение, и любая функция, в которую оно было брошено, в основном завершается.

Так что в коде, пытающемся создать этот объект или вызвать одного из его членов, я использую оператор Try ... Catch. Тем не менее, мне было интересно, что даже делать, когда это исключение поймано? Моему приложению нужны эти файлы, чтобы они были целы, а если нет, приложение практически бесполезно. Пока я просто выскакиваю сообщение, сообщающее пользователю, что это ошибка, и переустанавливаю. Что еще я могу сделать, или лучше, что является обычной практикой в ​​этих ситуациях?

Answer 1

ИМХО в системе существуют следующие типы исключений:

1. Восстанавливаемые исключения - это случаи, когда система может столкнуться с исключением, но затем может по умолчанию перейти в состояние, с которым она может продолжать работать, и показать пользователю, что она может продолжите с опцией по умолчанию, когда пользователь выберет «Продолжить», «Повторить» или «Отменить» операцию.

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

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

Answer 2

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

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

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

Также обратите внимание, что многие фреймворки имеют способ перехватывать все необработанные исключения, не заключая все это в блок Try Catch. Например, ASP.NET 3.5 использует класс Global.asax, который перехватывает все исключения. Поскольку наше приложение основано на веб-технологиях, это допускает любые ошибки, которые мы не ожидали, передать через этот класс, и мы можем отправлять разработчикам сообщения об ошибках и отображать соответствующую страницу ошибок пользователю. Хотя, естественно, если вы ожидаете возможного исключения в определенном блоке кода, вы можете просто установить Try-Catch вокруг этого блока, но для всех остальных это полезно.

Answer 3

Обычная практика - обрабатывать исключения, которые вы можете, и передавать (с необязательной регистрацией) те, которые вы не можете. Если вы столкнулись с проблемой, которую просто невозможно исправить, никакие повторные попытки не помогут, и правильный ответ - прекратить.

Answer 4

Нет реальных общих ответов на эту конкретную «проблему», но вот некоторые комментарии, которые могут вам помочь.

• Не нарушайте свои абстракции - Если ваш код вызывается на уровне, который работает с объектами, но ниже использует хранилище данных SQL, он не должен пропускать исключение SQL.

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

• Иерархии исключений - Это может относиться не ко всем языкам, но если вы можете структурировать свои исключения иерархически и можете отлавливать их деревья, а не только один, большая часть кода становится достаточно чистой .

Ваш подход в вашем случае звучит прилично. Сообщите пользователю, что произошла неустранимая ошибка, и прервите выполнение. Если заимствовать у отличного ответа Санни, он не подлежит восстановлению, поэтому вы должны запросить вмешательство пользователя. Лично я предпочел бы предупреждение и возврат к значению по умолчанию или к чему-то внутреннему, если это возможно, вместо сбоя и запроса переустановки.

Answer 5

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

Answer 6

В вашей конкретной ситуации это единственный путь.

В другой ситуации ... ну, это на самом деле зависит от ситуации.