一:概述
Spring MVC提供的统一全局异常处理能够很好解决异常信息直接返回的尴尬以及异常页面统一的问题。Spring Mvc提供了四种内置的异常处理实现,当然也可以自定义扩展实现异常处理,对于某些HTTP异常状态码web.xml中也可以针对状态码配置异常页面等
二:SimpleMappingExceeptionResolver
该异常处理实现是将异常类型与异常页面进行绑定处理,可以配置某种异常抛出时跳转特定的页面
2.1 配置详解
属性 | 类型 | 作用 | 备注 |
---|---|---|---|
order | Integer | 处理器执行顺序 | |
defaultErrorView | String | 默认所有异常跳转页面 | 处理的是没有特定配置的异常 |
exceptionAttribute | String | 异常页面中获取异常对象的key | 默认exception |
exceptionMappings | Propers | 定义需要绑定特定异常页面的异常类型 | |
excludedExceptions | Class[] | 该异常处理器不处理的异常 | |
defaultStatusCode | Integer | 异常处理器处理异常后返回HTTP请求的状态码 | 默认是200 |
statusCodes | Map<String,Integer> | 绑定某个异常页面的HTTP请求状态码 | key指定异常页面名字,value指定状态码 |
2.2 异常处理测试
SpringMVC配置文件中注入SimpleMappingExceeptionResolver实例,设置默认异常页面error.jsp,针对非法访问异常绑illegalAccess.jsp页面,不处理空指针异常,异常对象页面获取key为ex
控制层提供三个处理器,分别抛出空指针、非法状态、类转换异常。浏览器访问结果如下,符合配置需求
2.3 页面状态码测试
默认异常页面状态码为5000,当跳转到非法访问异常页面时状态码为6000
测试异常处理器处理类转换异常与非法访问异常,查看状态返回码符合配置
2.4 执行顺序测试
配置两个异常处理器,order执行顺序分别为1、2,通过跳转不同的异常页面判定异常处理器执行。当发生空指针异常时两个异常处理器都能执行,最后跳转页面为order属性为1的非法访问异常页面。结论就是order属性越小,异常处理器执行顺序越高
三:DefaultHandlerExceptionResolver
用以处理SpringMVC标准异常,将标准异常输出匹配HTTP标准状态码。比如当控制层定义支持请求类型为POST,发送GET请求,SpringMVC中将抛出HttpRequestMethodNotSupportedException。这时候异常处理器DefaultHandlerExceptionResolver就能捕获异常并进行处理,其处理源码示意如下
Response输出异常,异常状态码SC_METHOD_NOT_ALLOWED是在HttpServletResponse中定义常量405
四:ResponseStatusExceptionResolver
该异常处理器与DefaultHadlerExceptionResolver异常处理器一致,都是SpringMVC默认会装载的异常处理器。作用在于与@ResponseStatus注解配合,将注解中映射的HTTP状态码与异常描述输出到前端
五:ExceptionHandlerExceptionResolver
配合注解@ExceptionHandler使用的异常处理器,注解@ExceptionHandler限制要求必须与抛出异常方法在同一个类中才能生效,比较尴尬。结果就是每个类中都需要这么一个注解的方法,反正我不喜欢用这个异常处理,感兴趣可以自行Google
六:自定义异常处理
前面讲解的四个SpringMVC异常处理器实现都是HandlerExceptionResolver接口实现类,如果某些异常需要自定义逻辑处理则可以自行实现该接口定义异常处理器。该接口就一个方法resolveException(),该方法中重写异常处理逻辑
6.1 自定义异常处理器
6.2 测试自定义异常处理器
七:web.xml定义
当最终异常抛出到WEB容器中都未做任何处理的时候就可以在web.xml中配置定义异常页面,当然这里配置可以根据HTTP状态码亦或是异常进行配置。当请求抛出空指针异常会执行哪个error-page?根据作者的测试是当异常抛出会首先检查是否有定义<exception-type>,如果没有再根据Httpstatus进行处理