Фрагмент кода обработчика исключений - PullRequest
0 голосов
/ 09 ноября 2011

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

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

Ответы [ 6 ]

8 голосов
/ 09 ноября 2011

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

  • Иногда преобразует исключение одного типа в другой (хотя в C # это встречается реже, чем в Java; хорошо это или плохо - другое обсуждение)
  • Поймать ошибки в корне стека для определенного запроса / действия пользователя / чего угодно, обычно просто регистрируя результат
  • Обрабатывать API-интерфейсы с костью, которые генерируют исключения в неисключительных ситуациях

Ни один из них не занимает много времени, и ни один из них не появляется так часто, что стоит иметь общий фрагмент кода.

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

0 голосов
/ 10 ноября 2011

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

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

0 голосов
/ 09 ноября 2011

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

Тем не менее, когда вы используете локальную обработку исключений, и если по умолчанию try.snippet отсутствует, что-то вроде этого может работать (только включенный код, остальная часть файла .snippet немного очевидна):

try 
{           
  $selected$
}
catch ($caughtExceptionType$Exception ex)
{
  $end$
  Logger.Error("$message", ex);
  //throw new $customExceptionType$Exception("$message", ex);
}
0 голосов
/ 09 ноября 2011

Я бы порекомендовал вам использовать Кодовые контракты и такие инструменты AOP, как PostSharp. Они оба предоставляют отличные возможности для отладки и обработки ошибок вашего кода.

0 голосов
/ 09 ноября 2011

Следы стека (для тех, кто умеет их читать) составляют 90% от того, что вам нужно.Включение параметров, переданных в метод erroring, также НАСТОЯТЕЛЬНО поможет в отладке.Если это регистрация в базе данных, пожалуйста, будьте осторожны с регистрацией конфиденциальных фрагментов данных (PII или PHI).

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

0 голосов
/ 09 ноября 2011

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

...