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

@Ilya:

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

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

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

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

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

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

У Ned Batchelder есть превосходное (и намного дольше) отвечают Joel здесь. У Joel есть короткий ответ здесь, на который Ned отвечает снова здесь.

У Brad Abrams также есть очень хорошая статья о значении исключений здесь.

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

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

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

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

Конкретная.NET, но определенно имеет некоторую стоящую информацию.

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

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