Стратегии обработки исключений WCF - PullRequest
24 голосов
/ 04 марта 2010

Мы разрабатываем прокси в WCF, который будет служить средством связи для некоторых карманных компьютеров, на которых работает наше пользовательское клиентское приложение.Мне любопытно, какие стратегии обработки ошибок используют люди, поскольку я бы предпочел не заключать КАЖДЫЙ вызов прокси в try / catch.

Когда я разрабатываю ASP .NET, я не улавливаю большинство исключений, я использую Application_Error в Global asax, которыйЗатем можно зарегистрировать исключение, отправить электронное письмо и перенаправить пользователя на целевую страницу ошибки.То, что я ищу в WCF, похоже на это, за исключением того, что это позволило бы мне передать общую причину ошибки клиенту из центрального местоположения.

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

Спасибо

Ответы [ 3 ]

22 голосов
/ 04 марта 2010

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

15 голосов
/ 04 марта 2010

Итак, вот что я сделал. У нас есть несколько пользовательских исключений в нашем приложении, таких как BusinessRuleException и ProcessException, WCF поддерживает как FaultException, так и FaultException<T>.

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

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

Это решило часть проблемы, но я все еще хотел получить общий улов, который позволил бы мне централизовать ведение журнала. Я нашел это, используя интерфейс IErrorHandle и добавив свой собственный обработчик ошибок в WCF. Вот код:

public class ServiceHostGeneralErrorHandler : IErrorHandler
{
    public void ProvideFault(Exception ex, MessageVersion version, ref Message fault)
    {
        if (ex is FaultException)
            return;

        // a general message to the client
        var faultException = new FaultException("A General Error Occured");
        MessageFault messageFault = faultException.CreateMessageFault();
        fault = Message.CreateMessage(version, messageFault, null);
    }

    public bool HandleError(Exception ex)
    {
        // log the exception

        // mark as handled
        return true;
    }
}

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

2 голосов
/ 04 марта 2010

Мы используем блок «Приложение для обработки исключений» и скрываем большинство сбоев от клиентов, чтобы избежать разглашения конфиденциальной информации. Эта статья может быть хорошей отправной точкой для вас, как и в случае с «лучшими практиками» - вам следует подходит под ваш домен.

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