я видел в нескольких проектах своего рода поймать все исключения, чтобы поймать все неожиданное исключение, так что приложение не будет врезаться, я вижу это, как правило, с:Ловить все исключения хорошо или плохо?
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(myUnexpectedExhandler);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(threadExHandler);
Это хороший или плохой практикой.
Ловля исключений на верхнем уровне вашего проекта в порядке и правильном порядке. Там вы можете делать такие вещи, как вести журнал, сообщать подробности своей команде и т. Д. Исключения обязательно должны быть опубликованы где-то, если это вообще возможно, что очень помогает в разработке прочного продукта (см. Jeff Atwood's сообщение блога "Exception-Driven Development" для комментария к этому).
Что такое плохая практика, вы несете исключение из-за чрезмерного отклонения от стека вызовов. Единственный раз, когда вы должны поймать исключение, - это когда вы точно знаете, что с ним делать. Конечно, никогда, никогда, никогда, никогда не проглатывайте исключения.
+1 для этого 'Единственный раз, когда вы должны поймать исключение - это когда вы точно знаете, что с ним делать. ' – Martin
Но разве вы не должны проглатывать исключение, если это происходит при попытке регистрации исключения, так что вы не попадаете в цикл? – Kye
В этом случае он попадет в категорию «вы точно знаете, что с ней делать» - возможно, стоит рассмотреть какой-то резервный логгер, хотя, кроме того, если сам журнал исключений терпит неудачу, не так много ты можешь сделать. – jammycakes
В целом я бы сказал, что это зависит только от вас, но для меня это зависит от того, на какой стадии находится данный проект. Во время первоначальной разработки любого проекта я предпочитаю исключенные исключения для отображения приятного описательного сообщения об ошибке с какую строку кода он бомбил, поэтому я могу это исправить.
Как только сайт созревает, однако, я использую пользовательский класс ErrorHandler я построил и имеют все ошибки регистрируются в таблице базы данных, а также почасовую (или ежедневно) список ошибок по электронной почте разработчику отвечающий за проект. Специальные ошибки, требующие деликатной обработки, обычно имеют попытку/улов вокруг определенных строк кода, которые могут сломаться.
Каждый проект, над которым я работаю, в конечном итоге получает глобальный обработчик исключений.
Я лично не думаю, что это хорошая практика исключительно полагаться на это в производстве. Любой метод или действие, которое может вызвать выдачу исключения, должно обрабатываться на этом этапе (try..catch или передается классу обработчика custome и т. Д.). Это не только делает приложение более надежным, так как вы можете обрабатывать определенные исключения таким образом, который подходит для этой ситуации, но также облегчает выяснение причин исключения. Существует также множество фреймворков регистрации, которые облегчают протоколирование исключений и обработку ошибок.
Я бы использовал исключения «catch all», но только как самую последнюю строку обработки ошибок.
Я бы сказал, что это очень спорный вопрос среди многих программистов, которые имеют разные впечатления и имеют тенденцию иметь разные мнения. Мой ответ может быть немного длинным, но я чувствую, что не могу ответить на него коротко !!!
Я считаю, что в дальнейшем на основе моего опыта:
Чтобы добавить к вышеуказанным 2 пунктам, я также хотел бы сказать, что вы не можете восстановить какое-либо приложение, если необработанное приложение встречается в любом потоке, который вы создали. Только исключения в основном графическом потоке могут быть восстановлены.
Весь смысл добавления такого кода заключается в том, чтобы отладка и отчетность об ошибках стали проще и проще. Например, скажем, у вас очень большое приложение, и неожиданное исключение происходит где-то в вашем коде. Теперь, если у вас есть такие обработчики, как вы упомянули, вы можете централизовать все это и записать трассировку стека, сообщения и т. Д. И как только у вас будет весь журнал, это вопрос времени, чтобы решить проблему и узнать ее источник.
Надеюсь, это поможет!
Я регулярно использую такие исключения обработчики в производстве, и моя практика такова, что я могу использовать их:
НТН
По-моему, это очень хорошая практика, чтобы поймать и исключений в приложении уровня журнала.
BUT Это НЕ означает, что вам больше не нужно обрабатывать исключения, вам приходится обращаться к исключениям отдельных классов, которые вы изложили.
Исключения приложений должны использоваться только для того, чтобы программа не разбивалась и не использовалась для ведения журнала, а не для использования в качестве одной большой попытки захвата приложения.
Снова это было личное мнение.
Я думаю, что глобальный обработчик исключений был бы хорошим. Если ваша программа выйдет из строя, это позволит вам сделать одно пространство, чтобы попытаться выплюнуть еще один бит данных, чтобы вы могли, надеюсь, выяснить, почему он разбился. Восстановление из глобального обработчика исключений не будет предложено, потому что его, вероятно, не тот случай, когда вы знаете, как восстановить из произвольного исключения на верхнем уровне.
Если вы собираетесь регистрировать неперехваченное исключение, всегда регистрируйте его с помощью stacktrace! Я ненавижу получать сообщения об ошибках, которые имеют журнал, как: «Необработанное исключения» или «Необработанное исключение: IndexOutOfRangeException»
Спасибо, сослуживец. Замечательно.
http://forums.thedailywtf.com/forums/p/8499/161670.aspx (Извините, я просто должен был.) – Hello71
LOL это хороший lol – pdiddy