1html
错误处理有原理分析git
使用SpringBoot建立的web项目中,当咱们请求的页面不存在(http状态码为404),或者服务器发生异常(http状态码通常为500)时,SpringBoot就会给咱们返回错误信息。web
也就是说,在SpringBoot的web项目中,会自动建立一个/error的错误接口,来返回错误信息。可是针对不一样的访问方式,会有如下两种不一样的返回信息。这主要取决于你访问时的http头部信息的Accept
这个值来指定你能够接收的类型有哪些json
使用浏览器访问时的头信息及其返回结果后端
Accept: text/html
使用其余设备,如手机客户端等访问时头部信息及其返回结果(通常是在先后端分离的架构中)设计模式
Accept: */*
2浏览器
进行错误处理服务器
处理异常主要有两种方式:微信
1数据结构
使用SpringBoot的自动配置原理
SpringBoot自动配置了一个类ErrorMvcAutoConfiguration
来处理处理异常,有兴趣的能够去看一下,而后在这个类中定义一个错误的BasicErrorController类,主要代码有以下:
@Controller
@RequestMapping({"${server.error.path:${error.path:/error}}"})
public class BasicErrorController extends AbstractErrorController {
/**
* 错误的页面响应
*/
@RequestMapping(produces = {"text/html"})
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {
HttpStatus status = this.getStatus(request);
Map<String, Object> model = Collections.unmodifiableMap(this.getErrorAttributes(request, this.isIncludeStackTrace(request, MediaType.TEXT_HTML)));
response.setStatus(status.value());
// 获得一个modelAndView对象
ModelAndView modelAndView = this.resolveErrorView(request, response, status, model);
return modelAndView != null ? modelAndView : new ModelAndView("error", model);
}
/**
* 错误的json响应
*/
@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {
HttpStatus status = this.getStatus(request);
if (status == HttpStatus.NO_CONTENT) {
return new ResponseEntity(status);
} else {
Map<String, Object> body = this.getErrorAttributes(request, this.isIncludeStackTrace(request, MediaType.ALL));
return new ResponseEntity(body, status);
}
}
}
多的代码就不深究了,感兴趣的能够去看一下。上边的代码也就是说,针对不一样的请求方式,会返回不一样的结果,其关键在于@RequestMapping
注解的produces = {"text/html"}
属性上
有模板引擎的状况(能够用于渲染页面)
项目中使用的了模板引擎,如:thymeleaf 、freemarker等做为页面的渲染时。在templates建立/error文件夹并添加错误的状态码对应的.html文件,以下图:
这里的404和500就是肯定的错误状态码,而4xx表示其余的4开头的错误,如400,401等。固然能够为每个状态码都设置对应的错误页面,可是这样作,并无什么好处,因此就直接使用4xx.html这样的泛指代替了。
能够在咱们错误页面中获取到以下信息(就是ModelAndView对象中的内容):
细心的小伙伴会发现,这个其实就是当你用手机请求时返回的json内容
好比:在代码中加入上边信息,而后在在后端写一个错误代码:
@RequestMapping("haserror")
@ResponseBody
public Object myError(){
int i =10/0;
return "something is error";
}
这是一个错误页面:
<ul>
<li>错误状态码:[[${status}]]</li>
<li>错误消息:[[${error}]]</li>
<li>异常对象:[[${exception}]]</li>
<li>异常消息:[[${message}]]</li>
<li>当前时间:[[${timestamp}]]</li>
</ul>
没有模板引擎的状况
当项目中没有使用模板引擎的时候,就将整个error文件夹移到static文件夹下就能够了。
不过此时并不能获取上边的那些信息了,由于这本就是静态资源,没有模板引擎进行渲染
{
"timestamp": "2020-04-22T16:13:37.506+0000",
"status": 500,
"error": "Internal Server Error",
"message": "/ by zero",
"path": "/hello/haserror",
"reason": "完了,你写的代码又产生了一次线上事故"
}
这才是最重要的内容,由于这个信息不只是作为json返回的,也是能够在上边的错误页面中拿到,也能够直接返回一个json。其实也很简单,就是在Spring容器中添加一个ErrorAttributes
对象就能够了,这里我选择继承它的一个子类。
@Component
public class MyErrorAttributes extends DefaultErrorAttributes {
@Override
public Map<String, Object> getErrorAttributes(WebRequest webRequest, boolean includeStackTrace) {
//调用父类的方法,会自动获取内置的那些属性,若是你不想要,能够不调用这个
Map<String, Object> errorAttributes = super.getErrorAttributes(webRequest, includeStackTrace);
//添加自定义的属性
errorAttributes.put("reason","完了,你写的代码又产生了一次线上事故");
// 你能够看一下这个方法的参数webRequest这个对象,我相信你确定能发现好东西
return errorAttributes;
}
}
这就能够了,用两种请求方式分别测试一个咱们的这个自定义属性是否可用:
2
使用AOP的异常通知进行处理(推荐)
它的原理就是获取一个全局的异常通知,而后进行处理。咱们只须要在项目中写下边代码就能够了(其实上边也只是写了一个自定义异常信息的类)
若是对AOP有问题的小伙伴能够在后台回复Spring在教程中查看SpringAOP全系列文章
@ControllerAdvice
public class ErrroAcvice {
/**
* 全局捕获异常的切面类
* @param request 请求对象,可不传
* @param response 响应对象,可不传
* @param e 异常类(这个要和你当前捕获的异常类是同一个)
*/
@ExceptionHandler(Exception.class) //也能够只对一个类进行捕获
public void errorHandler(HttpServletRequest request, HttpServletResponse response,Exception e){
/*
* You can do everything you want to do
* 这里你拿到了request和response对象,你能够作任何你想作的事
* 好比:
*1.用request从头信息中拿到Accept来判断是请求方可接收的类型从而进行第一个方法的判断
*2.若是你也想返回一个页面,使用response对象进行重定向到本身的错误页面就能够了
* 3.你甚至还拿到了异常对象
*/
String accept = request.getHeader("Accept");
// 根据这个字符串来判断作出什么响应
try {
response.setStatus(500);
response.getWriter().write("hello");
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
总结与对比
第一种方法,就是在当前项目中放置一些错误状态码的页面让SpringBoot去查找。也支持自定义返回的错误信息
第二种方法,就是直接使用AOP的思想,进行异常通知处理,自由性很大。
我我的建议使用第二种方法,由于自由度很高,能够根据本身的业务逻辑进行随时改变,并且还有一个很大的用处。下一篇文章会有个很好的例子
使用了第二种方式后,经过第一种方式放置的错误页面和自定义错误信息所有失效
没代码,说什么都是瞎扯
关注公众号后台回复 2000 获取

2020-04-16

2020-04-14

微服务
设计模式
数据结构
关注我 有好货
本文分享自微信公众号 - 小鱼与Java(Fish_Java)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。