在上一篇教程中我为大家介绍了web api中filter的开发使用，其中讲到exceptionfilter时留了一个坑：exceptionfilter只能截获并处理action执行过程中发生的异常，在action执行过程之外如果出现异常，exceptionfilter是无能为力的。
      这些异常包括：
1、  controller构造方法中出现的异常
2、  messagehandlers中出现的异常
3、  路由过程中出现的异常
4、  body在序列化/反序列化过程中出现的异常
由此可以看出，exceptionfilter只能解决apicontroler成功实例化后并执行action期间出现的异常；为了解决这一个问题，在web api中除了exceptionfilter外还引入了两个针对异常记录、处理的扩展点：
iexceptionlogger 和iexceptionhandler。
         而这两个扩展是作为web api的管道组件进行注册管理的，并且，他们有不同的分工：
         iexceptionlogger作为异常日志记录组件，负责异常发生后的日志记录，他贯穿于整个web api的生命周期中，在web api框架里，任何一个请求周期中出现任何一个未被捕获/处理的异常都会首先进入这个异常日志记录管道进行异常log记录，在web api中可以注册多个iexceptionlogger实例负责不同的异常处理。
         iexceptionhandler作为异常处理组件，负责异常发生后的处理工作，他处于异常处理管道的最末端，当iexceptionlogger组件进行一场记录完毕、没有相关的exceptoinfilter进行异常处理时，才会最终调用exceptionhandler进行异常处理，在web api中，有且仅有一个exceptionhandler进行异常的处理。
         在web api框架中给出了两个基类：exceptionlogger和exceptionhandler，在使用exceptionlogger基类时，他提供了shouldlog虚方法，该方法在基类中被调用，其作用在于避免同一个异常被同一个exceptionlogger实例重复记录（如当后续的管道中该异常又被抛出，或者同一个exceptionlogger对象不小心被注册了两次就会出现重复记录的可能）我们也能复写shouldlog方法加入我们自己的异常记录判断逻辑以针对不同的场景进行不同的exceptionlogger调用。如果有兴趣可以反编译一下exceptionlogger基类看看，他使用了显示接口实现，挺有意思的一个技巧。下面我们来看一个exceptionlogger使用的例子：
public class errologger : exceptionlogger     {        public  async task logasync(exceptionloggercontext context, cancellationtoken cancellationtoken)         {            var sb = new stringbuilder();            //获取log组件             ilogger log = logmanager.getcurrentclasslogger();            var request = context.request;             sb.appendline(url:);            //获取url             var url = request.requesturi.tostring();             sb.appendline(url);                         log.error(context.exception,sb.tostring(),);         }        public override bool shouldlog(exceptionloggercontext context)         {            return context.exception is demoexception && base.shouldlog(context);         }     }
在这个例子中，我们重写了shouldlog，保证了这个exceptionlogger只记录demoexception这个类型的异常，并且也调用了基类方法，保证不会重复记录同一个异常。在logasync方法中，我通过log组件记录了导致异常的请求url，也记录了异常信息。
接下来我们要对这个组件进行注册：
在app_start/webapiconfig.cs文件中的register方法中写入
config.services.add(typeof(iexceptionlogger),new errologger());
这样，一个针对demoexception的异常记录组件就开发完成并注册完成了，当web api执行管道中出现未处理的demoexception异常，均会调用则个组件进行记录。
    接下来我们来写一个exceptionhandler，在整个web api框架中，exceptionhandler只能提供一个实例，与exceptionlogger一样，我们可以继承exceptionhandler基类来简化异常处理，在exceptionhandler中也提供了shouldhandle方法来判断该异常是否应该处理，避免重复处理管道中其他环节重复抛出的异常。我们也同样提供一个例子：
public class errorhandler : exceptionhandler     {        public override async task handleasync(exceptionhandlercontext context, cancellationtoken cancellationtoken)         {            if (context.exception is demoexception)             {                 context.result = new responsemessageresult(context.request.createresponse(httpstatuscode.badrequest,new {message=context.exception.message}));             }            else             {                 context.result = new responsemessageresult(context.request.createresponse(httpstatuscode.internalservererror,new {message = 服务器已被外星人绑架}));             }         } }
在这个例子中，我们判断了异常的类型，并根据不同的异常返回客户端不同的响应内容和不同的http状态码。
    然后在配置中注册这个异常处理模块，在app_start/webapiconfig.cs文件中的register方法中写入
config.services.replace(typeof(iexceptionhandler),new errorhandler());
这样就替换了系统默认的exceptionhandler，可以使用我们自定义的handler进行异常的处理了。
    在异常记录、处理过程中，我们都碰到相应的异常上下文参数，我们能通过这个参数获取当前请求的上下文，获取请求、响应（小心有时会为空哦）、捕获到该异常的catch块信息等内容，我们可以利用这些信息更好地描述、记录、处理异常。
    到这里exceptionlogger组件和exceptionhandler组件简单的开发就完成了。在开发的过程中我们可以看到，exceptionlogger负责了全局的异常记录，在web api框架管道下出现未处理的异常exceptionlogger都会进行捕获、记录。而exceptionhandler和exceptionfilter功能是有重叠的，那何时使用exceptionhandler何时使用exceptionfilter呢？我们可以将两者的区别列出如下的表格:
exceptionfilter
exceptionhandler
作用域
controller、action
全局
实例个数
无限制
全局唯一
作用条件
controller实例化成功之后
web api成功加载之后
经过上面的表我们可以看出，如果处理颗粒度细致到controller、action级别时，exceptionfilter处理起来会更得心应手，他已经能精确定位到某个action，然后可以针对当前action做定制开发。而exceptionhandler作用域远大于exceptionfilter，他处理全局更有优势。
关于web api异常处理的相关内容我就讲这么一些，如果在文章中有任何不正确的地方或者疑问，欢迎大家为我指出。
以上就是asp.net web api 异常处理经验总结的详细内容。