exception-handling - IExceptionLogger 是否不赞成在 Web API 2 中对 ExceptionFilterAttribute 的需求？

Question

根据官方文档中关于实现 IExceptionLogger 的讨论( http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling )链接到(现已过时？)关于实现 ExceptionFilterAttribute 的文章( http://www.asp.net/web-api/overview/testing-and-debugging/exception-handling )，是否有任何理由注册全局 ExceptionFilterAttribute如果您为 IExceptionLogger 注册服务?

我做到了，并且在调试 Controller 操作中生成的异常时，两种实现都处理了异常。所以IExceptionLogger由于文章中引用的所有原因，它是优越的。我们应该考虑ExceptionFilterAttribute已弃用？如果不是，为什么不呢？

Answer 1

重温这个话题，终于对IExceptionLogger之间的关系有了更深入的了解, ExceptionFilterAttribute , 和 IExceptionHandler .

来自不同的source of documentation从问题:

We provide two new user-replaceable services, IExceptionLogger and IExceptionHandler, to log and handle unhandled exceptions. The services are very similar, with two main differences: We support registering multiple exception loggers but only a single exception handler. Exception loggers always get called, even if we’re about to abort the connection. Exception handlers only get called when we’re still able to choose which response message to send. Both services provide access to an exception context containing relevant information from the point where the exception was detected, particularly the HttpRequestMessage, the HttpRequestContext, the thrown exception and the exception source (details below).

以及问题的实际答案:

Exception loggers are the solution to seeing all unhandled exception caught by Web API. Exception handlers are the solution for customizing all possible responses to unhandled exceptions caught by Web API. Exception filters are the easiest solution for processing the subset unhandled exceptions related to a specific action or controller.

以及说明各种类/接口(interface)之间关系的相关代码块(从 ExceptionFilterResult 反编译):

public async Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
{
  ExceptionDispatchInfo exceptionInfo;
  try
  {
    return await this._innerResult.ExecuteAsync(cancellationToken);
  }
  catch (Exception ex)
  {
    exceptionInfo = ExceptionDispatchInfo.Capture(ex);
  }
  Exception exception = exceptionInfo.SourceException;
  bool isCancellationException = exception is OperationCanceledException;
  ExceptionContext exceptionContext = new ExceptionContext(exception, ExceptionCatchBlocks.IExceptionFilter, this._context);
  if (!isCancellationException)
    await this._exceptionLogger.LogAsync(exceptionContext, cancellationToken);
  HttpActionExecutedContext executedContext = new HttpActionExecutedContext(this._context, exception);
  for (int i = this._filters.Length - 1; i >= 0; --i)
  {
    IExceptionFilter exceptionFilter = this._filters[i];
    await exceptionFilter.ExecuteExceptionFilterAsync(executedContext, cancellationToken);
  }
  if (executedContext.Response == null && !isCancellationException)
    executedContext.Response = await this._exceptionHandler.HandleAsync(exceptionContext, cancellationToken);
  if (executedContext.Response != null)
    return executedContext.Response;
  if (exception == executedContext.Exception)
    exceptionInfo.Throw();
  throw executedContext.Exception;
}