В чем принципиальное различие между двумя методами HandleException () блока обработки исключений (Ent Lib 4.1) - PullRequest
Новая
       9

В чем принципиальное различие между двумя методами HandleException () блока обработки исключений (Ent Lib 4.1)

0 голосов
/ 14 февраля 2009

В самой последней версии (4.1, выпущенной в октябре 2008 г.) блока приложения для обработки исключений в Microsoft Enterprise Library есть две сигнатуры метода HandleException (), и я немного растерялся по этому поводу, тем более документация, intellisense, а также приложения QuickStart не дают ощутимых отличий.

Вот две подписи: 

bool HandleException(Exception exceptionToHandle, string policyName);

bool HandleException(Exception exceptionToHandle, string policyName, out Exception exceptionToThrow);

Все примеры, которые я нашел, используют первый, как в этом примере, прямо из комментариев к документации XML по фактическому методу: 

try
{
   Foo();
}
catch (Exception e)
{
   if (ExceptionPolicy.HandleException(e, name)) throw;
}

И здесь, из того же источника (комментарии к документу XML для метода), приведен пример использования второго: 

try
{
   Foo();
}
catch (Exception e)
{
   Exception exceptionToThrow;
   if (ExceptionPolicy.HandleException(e, name, out exceptionToThrow))
   {
      if(exceptionToThrow == null)
         throw;
      else
         throw exceptionToThrow;
   }
}

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

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

Ответы [ 3 ]

3 голосов
/ 18 ноября 2009

Основное различие между перегрузками двух методов заключается в том, что 

bool HandleException(Exception exceptionToHandle, string policyName);

сгенерирует исключение, если PostHandlingAction имеет значение ThrowNewException.


Тогда как второй метод перегрузки: 

bool HandleException(Exception exceptionToHandle, string policyName, out Exception exceptionToThrow);

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

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

Таким образом, вторая перегрузка дает вам немного больше контроля, поскольку вы можете выполнить некоторую дополнительную логику перед броском. Он также стандартизирует API в том смысле, что если вы используете второй метод HandleException с параметром out, Enterprise Library никогда не будет преднамеренно обрабатывать ваше исключение и выдавать его за вас. Т.е. первый метод иногда вызывает, а иногда полагается на повторную передачу (в случае NotifyRethrow), но второй метод всегда возвращает и позволяет вызывающей программе выполнить бросок / повторную передачу.

3 голосов
/ 03 июня 2009

Если вы используете обработчик замены в конфигурации корпоративной библиотеки, ваше исключение замены будет возвращено с помощью второй подписи (вне Exception exceptionToThrow).

0 голосов
/ 08 июля 2009

Я полагаю, что вам не разрешено выбрасывать исходные исключения через границы служб WCF, это функция безопасности (действительно, чтобы убедиться, что конфиденциальная информация об ошибках не распространяется по цепочке услуг). Поэтому можно создать новое исключение и передать его с помощью второго параметра (Exception exceptionToThrow) и передать ему конкретное сообщение об исключении и тип с помощью вашей конфигурации (исключение замены корпоративной библиотеки). Одним из примеров которого является: 

            try
            {
                throw new InvalidCastException();
            }
            catch (InvalidCastException ex)
            {
                Exception ex1;
                bool rethrow = ExceptionPolicy.HandleException(ex, "ReplacePolicy1", out ex1);

                if (rethrow)
                {
                    throw new FaultException<ApplicationException>((ApplicationException)ex1, ex1.Message);
                }
            }

Создание FaultException (с контрактом Fault, установленным для операции WCF) не позволяет службе WCF сообщать об ошибке в состоянии сбоя в вызывающем приложении / службе.

Без второй подписи я бы боролся с упрощением / распространением ошибок через границы службы WCF.

Спасибо, Павел. (мод к коду 8/7/09 - исправление от Джона, спасибо)

...