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

Question

Кто-нибудь имеет лучшие практики для обработки исключений?

При поиске в Интернете я нахожу множество лучших практик на уровне кода (не перехватываю общие исключения, не перебрасываю новые исключения и т. Д.). Я ищу лучшие практики на более высоком уровне, например :

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

Любые мысли и помощь очень ценятся, спасибо.

Answer 1

@ Илья:

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

У Джоэла две проблемы с исключениями:

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

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

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

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

У Неда Батчелдера отличный (и гораздо более длинный) ответ Джоэлю здесь . У Джоэла короткий ответ здесь , на что Нед снова отвечает здесь .

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

Answer 2

.NET Специфично, но определенно содержит полезную информацию.

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

Answer 3

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

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

Это для меня ясный способ отделиться:

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

Answer 4

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