public class MyGlobalExceptionHandler : ExceptionHandler { public override void Handle(ExceptionHandlerContext context) { // here I handle them all,no matter sync or not } public override Task HandleAsync(ExceptionHandlerContext context,CancellationToken cancellationToken) { // not needed,but I left it to debug and find out why it never reaches Handle() method return base.HandleAsync(context,cancellationToken); } public override bool ShouldHandle(ExceptionHandlerContext context) { // not needed,but I left it to debug and find out why it never reaches Handle() method return context.CatchBlock.IsTopLevel; } }
我注册它在我的Global.asax Application_Start:
GlobalConfiguration.Configuration.Services.Replace(typeof(IExceptionHandler),new MyGlobalExceptionHandler());
一切工作正常,无论我抛出异常 – 内部控制器方法或我的自定义属性上面的控制器方法,无论我从AJAX请求或直接从浏览器调用它。
但是有一天,我需要CORS支持我的AJAX请求。我按照文章Enabling Cross-Origin Requests in ASP.NET Web API中所述启用了CORS
var cors = new EnableCorsAttribute("*","*","*"); // * is just for debugging purpose config.EnableCors(cors);
起初一切似乎都OK,CORS按预期工作,服务器响应OPTIONS请求。
但问题开始时,我想检查我的身份验证。突然,异常被吞下,我得到一个空的JSON {}响应,而不是我的自定义JSON格式化的异常,我在我的MyGlobalExceptionHandler的Handle()方法中创建。
在调试时,我惊讶地发现,现在对于AJAX请求ShouldHandle()方法只调用IsTopLevel = false,因此异常从不冒泡,从来没有达到我的Handle()方法。一旦我禁用CORS,一切再次正常(除了跨域请求,当然)。
为什么IsTopLevel从不是真的,当我启用CORS?我应该如何解决这个问题?
另一个副作用如下。如果禁用CORS,那么如果我在Handle()方法中抛出任何异常,它会到达Global.asax中的Application_Error处理程序。但是如果我启用CORS并抛出异常在我的处理程序方法,这些异常从来没有达到Application_Error。
更多详细信息:
看来,我发现这正是发生的时间。
如果在启用CORS时在控制器方法中抛出异常,那么CORS根本不会踢,并且不发送Access-Control-Allow-Origin头。当浏览器没有收到头,它立即中断请求,这种中断似乎也影响异常处理程序 – 它从来没有到达ShouldHandle()方法与IsTopLevel = true。
Chrome和Mozilla的行为就像这样,即使我运行AJAX请求从本地html文件到我的websiet在IIS Express localhost。
但情况在IE 11上有所不同。当我打开html文件在那里,它首先要求我有权限启用脚本。在我同意,然后IE 11忽略的事实,没有CORS头存在,它不会中断请求,因此我的异常处理程序接收IsTopLevel = true,并能够返回一个自定义的错误响应。
我想,这应该固定在Web API核心 – 即使我抛出异常,CORS应该仍然能够踢和发送其标题,所以浏览器接受响应。我创建了一个最小的测试用例应用程序,我将它发送到ASP.NET团队的CodePlex。
Link to the test project.(项目zip文件将被标记,只需点击下载并忽略该文件夹中的所有其他文件)
解决方法
看来,WebAPI默认情况下是使用这个异常处理程序:
它与本文中建议的异常处理有很大的不同:
http://www.asp.net/web-api/overview/web-api-routing-and-actions/web-api-global-error-handling
参见“附录:基类细节”一章,其中给出了默认异常基类的代码。
在这个例子中,它检查IsOutmostCatchBlock(现在似乎被移动到exceptionContext.CatchBlock.IsTopLevel),看看是否是时候处理异常。当启用CORS时,由于上述原因,此方法将不起作用。 ASP.NET团队说,这种行为是通过设计,他们不会改变任何东西。
我希望有经验的人会写一个最新的文章,说明如何处理异常处理与CORS和没有CORS的正确方式。
>不从System.Web.Http.ExceptionHandling.ExceptionHandler继承我的自定义异常处理程序,但直接实现IExceptionHandler
>如果从System.Web.Http.ExceptionHandling.ExceptionHandler继承,覆盖
ShouldHandle方法并返回true总是因为CatchBlock.IsTopLevel可能永远不具有真值。
我试过两个apporaches,他们似乎工作正常。