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，他们似乎工作正常。
