尽管我喜欢Darin的答案,但它并不适用于我们的情况,因为ASP.NET MVC Web API框架在内部抑制/处理异常,而不是重新抛出以触发Global.asax中的Application_Error方法。我们的解决方案是
我结束了创建自定义DelegatingHandler像这样:
public class PrincipalHandler : DelegatingHandler
{
protected const string PrincipalKey = "MS_UserPrincipal";
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
setAnonymousPrincipal();
request = InitializeIdentity(request);
return base.SendAsync(request, cancellationToken)
.ContinueWith(r =>
{
// inspect result for status code and handle accordingly
return r.Result;
});
}
}
我那么插入它到HttpConfiguration,以确保它是第一个/最后一个处理程序被击中。处理程序在Web API中的工作方式是分层次的。因此,第一个处理器将按照请求进行处理,将成为响应中最后一个处理器。至少这是我的理解,如果我错了,有人可以随时纠正我。
public static void ConfigureApis(HttpConfiguration config)
{
config.MessageHandlers.Insert(0, new PrincipalHandler());
}
通过使用这种方法,我们现在可以检查来自Web API和控制器的任何响应中返回的每个结果。这使我们能够处理任何可能需要发生的日志记录,这些日志记录不会像我们预期的那样返回。我们现在还可以更改返回的响应内容,以便IIS在看到某些HTTP状态代码时不会插入任何默认的HTML错误页面。
我有这个唯一的问题,我希望他们改变它即将发布的Web API,是他们不会发送异常备份在从base.SendAsync返回的任务( )。因此,我们唯一需要的信息就是HTTP状态代码,并尽力为消费者提供合理或可能的答案。
这种感觉错了。你是否在某个库中抛出异常?为什么不在控制器中捕获异常并返回您自己选择的错误视图? – 2012-04-23 16:48:41
这是使用ASP.NET MVC Web API,所以我们没有从控制器返回视图。我们返回JSON/XML响应。我在我的问题中还提到,在他们到达控制器之前,我需要一种处理异常的方法。现在我们拥有一个ExceptionFilter,一旦我们进入控制器,就可以在任何地方捕获异常,所以我们不必在每个操作中都有try/catch。 – phreak3eb 2012-04-23 18:23:20
我不认为我完全理解你的问题。你试图准确捕捉什么类型的错误? – cecilphillip 2012-04-23 19:05:21