Блок обработки исключений Microsoft - разве это не идеальный пример чрезмерной разработки?

StackOverflow https://stackoverflow.com/questions/408480

Вопрос

С тех пор как Microsoft представила блоки приложений, я постоянно сталкиваюсь с людьми, которые используют Блок приложения для обработки исключений.Недавно я сам присмотрелся повнимательнее и хотел бы кратко описать основные функциональные возможности следующим образом (пропустите следующий блок, если вы уже знаете, что он делает):

Прикладной блок обработки исключений направлен на централизацию и полную настройку с помощью конфигурационных файлов следующего ключевые задачи по обработке исключений:

  • Регистрация исключения
  • Замена исключения
  • Обертывание исключения
  • Распространение исключения
  • и т.д.

Библиотека делает это, предлагая вам изменить ваши блоки try catch следующим образом:

try
{
  // Run code.
}
catch(DataAccessException ex)
{
    bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
    if (rethrow)
    {
        throw;
    }
}

Основываясь на том, что указано в app.config для имени политики (смотрите документы здесь), HandleException также не будет ...

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

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

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

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

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

Это было полезно?

Решение

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

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

Например, если вы разрабатываете API, вы можете захотеть, чтобы каждая функция в вашем API выдавала только стандартные исключения (ArgumentException, и т.д.), А также ваше собственное исключение для конкретной библиотеки в случае внутреннего нестандартного исключения (напримерa MyLibraryException).В подобных случаях все, что имеет значение, - это то, что что-то сработало неправильно.Вы не разбираете исключение и не выясняете, что пошло не так.Вы просто признаете тот факт, что некоторыечто-то пошло не так, и это вы должны были сделать некоторыедело сейчас.

Это некоторыевещь должна быть настраиваемой, потому что на самом деле не имеет значения, что вы делаете.Отображать окно сообщения пользователю?Модальный или немодальный?Зарегистрировать исключение?Как вы хотите зарегистрировать исключение?Вызвать веб-службу ведения журнала?Добавить в файл журнала?Запись в журнал событий Windows?Вставить запись в базу данных?Вставить запись в две базы данных?На самом деле это не имеет значения для остальной части вашего приложения.Выбор способа обработки исключения полностью ортогональен остальной части приложения.

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

Другие советы

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

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

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

Прежде чем начать, я признаю, что мне действительно нравится Экранирование исключений на границах службы WCF функциональность.Однако это было добавлено сравнительно недавно, не включает в себя кодирование - только атрибуты и конфигурацию, и обычно блок продается не так.Вот как Microsoft показывает это на http://msdn.microsoft.com/en-us/library/cc309250.aspx

alt text

На мой взгляд, все вышесказанное - это управление потоком. 

try
{
  // Run code.
}
catch(DataAccessException ex)
{
    bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
    if (rethrow)
    {
        throw;
    }
}

Когда вы объединяете аспект управления потоком с приведенным выше кодом, вы определенно не чтобы неправильный код выглядел неправильно.(Неважно, что конструкция if (rethrow) не предлагает большой абстракции.) Это может усложнить обслуживание для разработчиков, незнакомых с определениями политики.Если postHandlingAction при изменении файла конфигурации (вероятно, это произойдет в какой-то момент) вы, вероятно, обнаружите, что приложение ведет себя неожиданным образом, который никогда не тестировался.

Возможно, я бы не счел это нежелательным, если бы блок не обрабатывал управление потоком, а просто позволял вам объединять обработчики вместе.

Но, возможно, и нет.На самом деле я не помню, чтобы меня когда-либо об этом просили:

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

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

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

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

умное программирование, если хотите знать мое мнение...

Все очень просто:если вы хотите, чтобы обработка исключений в вашем коде выпуска отличалась от обработки в коде отладки, то это было бы полезно.

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

bool rethrow = ExceptionPolicy.HandleException (например, "Политика доступа к данным");

Одна строка кода - насколько простым вы можете его получить?За одной строкой кода политика в том виде, в каком она настроена, позволяет легко выполнять назначение / обновления политики, и все это без необходимости перекомпиляции исходного кода.

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

Я бы сказал, сложный, но не чрезмерно инженерный.Итак, я думаю, что большие дивиденды будут видны во время обслуживания, когда вам нужно будет изменить способ обработки / протоколирования исключений, обладая гибкостью для легкого изменения конфигурации и сохраняя ту же самую одну строку исходного кода.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top