Ведение журнала исключений для служб WCF с использованием ELMAH - PullRequest
62 голосов
/ 22 мая 2009

Мы используем превосходный ELMAH для работы с необработанными исключениями в веб-приложении ASP.NET 3.5. Это работает очень хорошо для всех сайтов, кроме служб WCF, которые используются с использованием функций REST. Когда в методах операций возникает исключение, которое не обрабатывается кодом приложения, WCF обрабатывает его различными способами в зависимости от сервисных контрактов и параметров конфигурации. Это означает, что исключение не приводит к возникновению события ASP.NET HttpApplication.Error, которое использует ELMAH . Мне известно о двух решениях:

  • Обернуть все вызовы методов в try {} catch (Exception ex) {Elmah.ErrorSignal.FromCurrentContext (). Raise (ex); бросить; } явно вызвать Elmah в блоке catch.
  • Используйте IErrorHandler , как описано в Will Hughes ' сообщение в блоге Совмещение игр WCF и ELMAH вместе , чтобы выделить вызов ELMAH для отдельного ErrorHandler.

Первый вариант чрезвычайно прост, но не совсем DRY . Второй вариант требует, чтобы вы украсили каждый сервис пользовательским атрибутом после реализации атрибута и ErrorHandler. Я сделал это на основе Will's работы, но я хочу убедиться, что это правильный подход перед отправкой кода.

Есть ли лучший способ, который я пропустил?

В документации MSDN для IErrorHandler говорится, что метод HandleError является местом для ведения журнала, но ELMAH обращается к HttpContext.Current. ApplicationInstance , который является нулевым в этом методе, даже если HttpContext.Current доступен. Выполнение вызова Elmah в методе ProvideFault - это обходной путь, так как ApplicationInstance установлен, но это не соответствует намерению, описанному в документации API. Я что-то здесь упускаю? В документации указано, что вам не следует полагаться на метод HandleError, вызываемый в потоке операций, что может быть причиной того, что ApplicationInstance имеет значение null в этой области.

Ответы [ 6 ]

88 голосов
/ 25 мая 2009

Решение из моего поста в блоге (на которое ссылается OP) было основано на существующем решении, которое мы использовали / используем для изменения кодов ответа HTTP во время состояния ошибки.

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

Для Posterity / Reference и потенциального улучшения - вот код текущего решения.

Классы HttpErrorHandler и ServiceErrorBehaviourAttribute

using System;
using System.ServiceModel;
using System.ServiceModel.Dispatcher;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.Collections.ObjectModel;
using System.Net;
using System.Web;
using Elmah;
namespace YourApplication
{
    /// <summary>
    /// Your handler to actually tell ELMAH about the problem.
    /// </summary>
    public class HttpErrorHandler : IErrorHandler
    {
        public bool HandleError(Exception error)
        {
            return false;
        }

        public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
        {
            if (error != null ) // Notify ELMAH of the exception.
            {
                if (System.Web.HttpContext.Current == null)
                    return;
                Elmah.ErrorSignal.FromCurrentContext().Raise(error);
            }
        }
    }
    /// <summary>
    /// So we can decorate Services with the [ServiceErrorBehaviour(typeof(HttpErrorHandler))]
    /// ...and errors reported to ELMAH
    /// </summary>
    public class ServiceErrorBehaviourAttribute : Attribute, IServiceBehavior
    {
        Type errorHandlerType;

        public ServiceErrorBehaviourAttribute(Type errorHandlerType)
        {
            this.errorHandlerType = errorHandlerType;
        }

        public void Validate(ServiceDescription description, ServiceHostBase serviceHostBase)
        {
        }

        public void AddBindingParameters(ServiceDescription description, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection parameters)
        {
        }

        public void ApplyDispatchBehavior(ServiceDescription description, ServiceHostBase serviceHostBase)
        {
            IErrorHandler errorHandler;
            errorHandler = (IErrorHandler)Activator.CreateInstance(errorHandlerType);
            foreach (ChannelDispatcherBase channelDispatcherBase in serviceHostBase.ChannelDispatchers)
            {
                ChannelDispatcher channelDispatcher = channelDispatcherBase as ChannelDispatcher;
                channelDispatcher.ErrorHandlers.Add(errorHandler);
            }
        }
    }
}

Пример использования

Украсьте свои службы WCF с помощью атрибута ServiceErrorBehaviour:

[ServiceContract(Namespace = "http://example.com/api/v1.0/")]
[ServiceErrorBehaviour(typeof(HttpErrorHandler))]
public class MyServiceService
{
  // ...
}
9 голосов
/ 17 июня 2011

При создании элемента BehaviorExtensionElement можно даже активировать поведение, используя config:

public class ErrorBehaviorExtensionElement : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get { return typeof(ServiceErrorBehaviourAttribute); }
    }

    protected override object CreateBehavior()
    {
        return new ServiceErrorBehaviourAttribute(typeof(HttpErrorHandler));
    }
}

Config:

<system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name="elmah" type="Namespace.ErrorBehaviorExtensionElement, YourAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <elmah />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Таким образом, можно также использовать ELMAH в сочетании с услугами RIA!

2 голосов
/ 05 декабря 2013

Это может быть очевидным для некоторых людей, но я просто потратил некоторое время, пытаясь выяснить, почему мой HttpContext.Current был нулевым, несмотря на то, что следовал всем превосходным ответам Уилла Хьюза. Смущающе, я понял, что это потому, что моя служба WCF активируется сообщением MSMQ.

Я переписал метод ProvideFault():

if (HttpContext.Current == null)
{
    ErrorLog.GetDefault(null).Log(new Error(error));
}
else
{
    ErrorSignal.FromCurrentContext().Raise(error);
}
2 голосов
/ 22 мая 2009

Я сделал это на основе работы Уилла но я хочу убедиться, что это правильный подход перед публикацией Код.

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

Марк

1 голос
/ 05 декабря 2013

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

protected override void HandleException(HandleExceptionArgs args)
{
    Elmah.ErrorSignal.FromCurrentContext().Raise(args.Exception);
    base.HandleException(args);
}
0 голосов
/ 22 мая 2009

Я не пробовал делать это явно с REST и сам не использовал ELMAH, но другой вариант, который стоит изучить, может заключаться в подключении к WCF с использованием IDispatchMessageInspector вместо IErrorHandler.

...