Это плохая практика - регистрировать исключение, только когда оно поймано?

Question

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

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

Answer 1

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

Если пользователь запросил, например, открыть файл, и вы поймете FileNotFoundException, уместно сообщить об этом пользователю и предоставить ему возможность выбрать другой файл. Или, если анализ предоставленной пользователем строки вызывает FormatException (хотя вы часто будете использовать шаблон TryX , чтобы избежать исключений здесь), скажите пользователю ввести числовую строку.

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

Answer 2

Некоторые исключения указывают на то, что все происходит очень плохо, и приложение должно быть закрыто настолько быстро, насколько это практически возможно, чтобы избежать повреждения системы; данные могут быть сохранены в файле восстановления, но не должны перезаписывать основной файл. Другие исключения указывают на то, что произошла неожиданная, но исправимая ситуация. Другие указывают, что Microsoft не использовала метод Try___, который они должны были включить в API (например, Control.TryBegininvoke). В прежней ситуации съесть исключение было бы очень плохо. В последней ситуации употребление исключения является самым чистым способом получения рабочего кода (обходные пути, необходимые для того, чтобы Control.BeginInvoke не генерировал, ужасны и могут вызвать больше разногласий, чем проглатывание исключений из BeginInvoke). В средней ситуации обработчик исключений должен исправить ситуацию, чтобы модуль, содержащий его, мог подчиняться своим контрактам. Если это можно сделать, нет необходимости распространять исключение дальше.

Answer 3

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

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

Answer 4

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

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