Microsoft Exception Handling Block - Разве это не идеальный пример для сверхразработки?

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

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

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

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

умное программирование, если Вы спрашиваете меня...

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

По-моему, одно действительное значение использования блока Обработки исключений начинается с одной строки кода в Вашем блоке выгоды:

bool повторно бросают = ExceptionPolicy. HandleException (исключая, "политика Доступа к данным");

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

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

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

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

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

Для моих глаз вышеприведенное - это управление потоком.

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

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

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

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

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

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