- 源码解析
- 1. 异常处理源码解析
- 1.1 测试方法编写
- 1.2 源码 debug
版本信息：SpringBoot 2.6.1
1. 异常处理源码解析 1.1 测试方法编写@RestController
@Slf4j
public class TestController {
@GetMapping("/user/{id}")
public User user(@PathVariable Integer id) {
log.info("查询用户信息id={}", id);
// 制造空指针异常
User user = null;
user.setName("张三");
user.setAge(18);
return user;
}
}
1.2 源码 debug
使用 postman 发起请求看一下空指针异常是如何被处理的
首先我们要找到 org.springframework.web.servlet.DispatcherServlet#doDispatch ，web请求处理的核心方法就从这里开始
我们直接从发生异常后开始看，被捕获的异常赋值给 dispatchException，然后调用 processDispatchResult() 进入视图解析流程处理返回值
接下来判断异常是否为空，这里是一个空指针异常所以不为空，并且当前异常并不是 ModelAndViewDefiningException 类型，所以进入了 else 中的流程调用 processHandlerException() 处理异常
接下来遍历所有的异常处理器 handlerExceptionResolvers 对当前异常进行处理。如下所示默认的异常处理器有如下4个（DefaultErrorAttributes 和 HandlerExceptionResolverComposite 为三个解析器的组合），如果可以处理并且返回的 exMv 不为 null 就会结束遍历
第一个 DefaultErrorAttributes 只做了一件事情，将异常保存到 request 域中
最终没有处理器可以处理当前异常
最终异常被抛出
抛出的异常再次被捕获，然后执行了拦截器的 afterCompletion() 方法
放行断点，至此 doDispatch() 的方法就执行完了，你可能会疑惑异常并没有被处理。此时神奇的事情就发生了，放行断点之后再次进入了 doDispatch() 方法，出现了一个 /error 请求，所以没有处理器可以处理的请求会再次发送一个 /error
进入 ha.handle() 中查看一下 /error 是如何被处理的
调用 doInvoke() 方法时，就来到了默认的 BasicErrorController 的 error 方法中。对于请求处理过程不熟悉的可以看我的另一篇文章 【SpringBoot2—Web请求处理源码解析】
注意在这里你发起请求的方式不同，进入的方法也不同
