Ловить все исключения хорошо или плохо?

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

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(myUnexpectedExhandler);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(threadExHandler);

Это хорошая или плохая практика.

ОТВЕТЫ

Ответ 1

Исключение исключений на верхнем уровне вашего проекта является правильным и правильным. Там вы можете делать такие вещи, как регистрировать его, сообщать о деталях своей команде и т.д. Исключения обязательно должны быть опубликованы где-то, если это вообще возможно, что помогает в разработке продукта с твердой твердостью (см. Jeff Atwood blog post " Exception-Driven Development" для комментария к этому).

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

Я лично не считаю хорошей практикой исключительно полагаться на это на производстве. Любой метод или действие, которое может вызвать выдачу исключения, должно обрабатываться на этом этапе (try..catch или передается классу обработчика custome и т.д.). Это не только делает приложение более надежным, так как вы можете обрабатывать определенные исключения таким образом, который подходит для этой ситуации, но также облегчает выяснение причин исключения. Существует также множество фреймворков регистрации, которые облегчают запись исключений и обработку ошибок.

Я бы использовал исключения "catch all", но только как самую последнюю строку обработки ошибок.

Ответ 5

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

Я верю в следующее, исходя из моего опыта:

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

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

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

Надеюсь, это поможет!

Ответ 6

По моему мнению, очень хорошая практика ловить и записывать исключения на уровне приложений.

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

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

Снова это было личное мнение.

Ответ 7

Я регулярно использую такие обработчики исключений в производстве, и моя практика заключается в том, что я могу использовать их для:

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

НТН

Ответ 8

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

Ответ 9

Если вы собираетесь регистрировать неперехваченное исключение, всегда регистрируйте его с помощью stacktrace! Я ненавижу получать сообщения об ошибках, у которых есть журнал: "Необработанное исключение" или "Необработанное исключение: IndexOutOfRangeException"

Спасибо, коллеги. Это здорово.