Исключением является ошибка блокировки .
Прежде всего, лучшая практика должна заключаться в том, чтобы не выдавать исключения для любых ошибок, если только это не ошибка блокировки .
Если ошибка блокирует , то сгенерируйте исключение. Как только исключение уже выброшено, его не нужно скрывать, потому что оно исключительное; сообщите пользователю об этом (вам следует переформатировать все исключение, чтобы пользователь получил что-то полезное в пользовательском интерфейсе).
Ваша задача как разработчика программного обеспечения состоит в том, чтобы постараться предотвратить исключительный случай, когда какой-либо параметр или ситуация во время выполнения могут закончиться исключением. То есть исключения не должны быть отключены, но их следует избегать .
Например, если вы знаете, что некоторые целочисленные данные могут иметь неправильный формат, используйте int.TryParse
вместоint.Parse
. Есть много случаев, когда вы можете сделать это вместо того, чтобы просто сказать «если это не удастся, просто выбросить исключение».
Бросать исключения стоит дорого.
Если, в конце концов, выдается исключение, а не записывать исключение в журнал после того, как оно было сгенерировано, одна из лучших рекомендаций - перехватить его в обработчике исключений первого шанса . Например:
- ASP.NET: Global.asax Application_Error
- Другие: событие AppDomain.FirstChanceException .
Моя позиция заключается в том, что локальные try / catches лучше подходят для обработки особых случаев, когда вы можете перевести исключение в другое или если вы хотите «отключить» его для очень, очень, очень, очень, очень особого случая (ошибка библиотеки выбрасывание несвязанного исключения, которое необходимо отключить, чтобы обойти всю ошибку).
Для остальных случаев:
- Старайтесь избегать исключений.
- Если это невозможно: обработчики исключений первого шанса.
- Или используйте аспект PostSharp (AOP).
Отвечая на @thewhiteambit на некоторый комментарий ...
@ thewhiteambit сказал:
Исключения не являются фатальными ошибками, они являются исключениями! Иногда они даже не являются ошибками, но считать их фатальными ошибками - совершенно неверное понимание того, что такое исключения.
Прежде всего, как исключение не может быть даже ошибкой?
- Нет подключения к базе данных => исключение.
- Неверный формат строки для разбора на исключение типа =>
- Попытка разобрать JSON, и хотя ввод не является JSON => исключением
- Аргумент, в
null
то время как объект ожидался => исключение
- В некоторых библиотеках есть ошибка => выдает неожиданное исключение
- Есть сокетное соединение, и оно отключается. Затем вы пытаетесь отправить сообщение => исключение
- ...
Мы могли бы перечислить 1 000 случаев, когда выдается исключение, и в конце концов, любой из возможных случаев будет ошибкой .
Исключением является ошибка, потому что в конце дня это объект, который собирает диагностическую информацию - у него есть сообщение, и это происходит, когда что-то идет не так.
Никто не бросил бы исключение, когда нет исключительного случая. Исключения должны блокировать ошибки, потому что после их появления, если вы не попытаетесь использовать try / catch и исключения для реализации потока управления, это означает, что ваше приложение / служба остановит операцию, которая вошла в исключительный случай .
Кроме того, я предлагаю всем проверить парадигму быстрого отказа, опубликованную Мартином Фаулером (и написанную Джимом Шором) . Именно так я всегда понимал, как обрабатывать исключения, даже до того, как попал в этот документ некоторое время назад.
[...] считать их «Фатальными ошибками» - совершенно неверное понимание того, что такое исключения.
Обычно исключения сокращают некоторый поток операций, и они обрабатываются, чтобы преобразовать их в понятные человеку ошибки. Таким образом, кажется, что исключение на самом деле является лучшей парадигмой для обработки случаев ошибок и работы над ними, чтобы избежать полного сбоя приложения / службы и уведомить пользователя / потребителя, что что-то пошло не так.
Больше ответов о проблемах @thewhiteambit
Например, в случае отсутствия соединения с базой данных программа может в исключительном случае продолжить запись в локальный файл и отправить изменения в базу данных, как только она снова станет доступной. Ваш недопустимый приведение типа String-to-Number можно попытаться снова проанализировать с языковым переводом в Exception, например, если вы попытаетесь выполнить разбор по умолчанию с английского языка на Parse ("1,5"), и вы попробуете его снова с немецким переводом, который полностью хорошо, потому что мы используем запятую вместо точки в качестве разделителя. Вы видите, что эти исключения не должны даже блокировать, им нужна только некоторая обработка исключений.
Если ваше приложение может работать в автономном режиме без сохранения данных в базе данных, вы не должны использовать исключения , так как использование потока управления try/catch
рассматривается как анти-шаблон. Автономная работа - это возможный вариант использования, поэтому вы реализуете поток управления, чтобы проверить, доступна ли база данных или нет, и вы не ждете, пока она не станет недоступной .
Разборе вещь также ожидаемый случай ( не исключительный случай ). Если вы ожидаете этого, вы не используете исключения для управления потоком! , Вы получаете метаданные от пользователя, чтобы узнать, какова его / ее культура, и для этого вы используете средства форматирования! .NET также поддерживает эту и другие среды, и это исключение, поскольку следует избегать форматирования чисел, если вы ожидаете, что ваше приложение / служба будет зависеть от конкретной культуры .
Необработанное исключение обычно становится ошибкой, но само исключение не является codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors
Эта статья просто мнение или точка зрения автора.
Так как Википедия может быть просто мнением автора (ов) статьи, я бы не сказал, что это догма , но проверь, что в статье « Кодирование за исключением» говорится где-то в некотором абзаце:
[...] Использование этих исключений для обработки конкретных ошибок, возникающих при продолжении программы, называется кодированием по исключению. Этот анти-шаблон может быстро ухудшить производительность программного обеспечения и его ремонтопригодность.
Это также говорит где-то:
Неправильное использование исключения
Часто кодирование по исключению может привести к дальнейшим проблемам в программном обеспечении с неправильным использованием исключения. В дополнение к использованию обработки исключений для уникальной проблемы, неправильное использование исключений делает это еще более важным, выполняя код даже после возникновения исключения. Этот плохой метод программирования напоминает метод goto во многих языках программного обеспечения, но возникает только после обнаружения проблемы в программном обеспечении.
Честно говоря, я считаю, что программное обеспечение не может быть разработано без серьезного рассмотрения вариантов использования. Если вы это знаете ...
- Ваша база данных может перейти в автономный режим ...
- Некоторые файлы могут быть заблокированы ...
- Некоторое форматирование может не поддерживаться ...
- Некоторая проверка домена может завершиться ошибкой ...
- Ваше приложение должно работать в автономном режиме ...
- в любом случае ...
... вы не будете использовать исключения для этого . Вы бы поддержали эти варианты использования, используя регулярный поток управления.
И если какой-то неожиданный вариант использования не будет рассмотрен, ваш код быстро потерпит неудачу, потому что он выдаст исключение . Правильно, потому что исключение - исключительный случай .
С другой стороны, и, наконец, иногда вы покрываете исключительные случаи, выбрасывая ожидаемые исключения , но вы не бросаете их для реализации потока управления. Вы делаете это потому, что хотите уведомить верхние уровни о том, что вы не поддерживаете какой-либо вариант использования или ваш код не работает с некоторыми заданными аргументами или данными / свойствами среды.