Архитектура обработки исключений

Есть ли у кого-нибудь лучшие методы обработки исключений?

При поиске в Интернете я нахожу много лучших практик на уровне кода (не перехватывайте общие исключения, не ревертируйте новые исключения и т.д.) То, что я ищу, - это лучшие практики на более высоком уровне, например

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

Любые мысли и помощь приветствуются, спасибо.

ОТВЕТЫ

Ответ 1

@Ilya:

Это, вероятно, одна из худших статей, которые когда-либо писал Джоэл (для тех, кто не читал ссылку, он утверждает, что "Исключения считаются вредными", поэтому не используйте их).

Joel имеет две проблемы с исключениями:

  • Они невидимы в исходном коде.

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

  • Они создают слишком много возможных точек выхода для функции.

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

Ned Batchelder имеет отличный (и гораздо более длинный) ответ на Joel здесь. У Джоэля есть короткий ответ здесь, на который Ned снова отвечает здесь.

Брэд Абрамс также имеет очень хорошую статью о значении исключений здесь.

Ответ 3

Мне также нравится различать:

  • исключение из-за вызывающей функции
  • исключение из-за внутренней ошибки внутри функции.

Это для меня четкий способ разделить:

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

Ответ 4

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