总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://frapples.github.io/articles/2018-09-01-ecbc.html 「Frapples」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

在具体的SSM项目开发中，由于Controller层为处于请求处理的最顶层，再往上就是框架代码的。 因此，肯定需要在Controller捕获所有异常，并且做适当处理，返回给前端一个友好的错误码。

不过，Controller一多，我们发现每个Controller里都有大量重复的、冗余的异常处理代码，很是啰嗦。 能否将这些重复的部分抽取出来，这样保证Controller层更专注于业务逻辑的处理， 同时能够使得异常的处理有一个统一的控制中心点。

1. 全局异常处理

1.1. HandlerExceptionResolver接口

public interface HandlerExceptionResolver {

	/**
	 * Try to resolve the given exception that got thrown during on handler execution,
	 * returning a ModelAndView that represents a specific error page if appropriate.
	 * <p>The returned ModelAndView may be {@linkplain ModelAndView#isEmpty() empty}
	 * to indicate that the exception has been resolved successfully but that no view
	 * should be rendered, for instance by setting a status code.
	 * @param request current HTTP request
	 * @param response current HTTP response
	 * @param handler the executed handler, or {@code null} if none chosen at the
	 * time of the exception (for example, if multipart resolution failed)
	 * @param ex the exception that got thrown during handler execution
	 * @return a corresponding ModelAndView to forward to,
	 * or {@code null} for default processing
	 */
	ModelAndView resolveException(
			HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex);
}

使用全局异常处理器只需要两步：

  1. 实现HandlerExceptionResolver接口。
  2. 将实现类作为Spring Bean，这样Spring就能扫描到它并作为全局异常处理器加载。

在resolveException中实现异常处理逻辑。 从参数上，可以看到，不仅能够拿到发生异常的函数和异常对象，还能够拿到HttpServletResponse对象，从而控制本次请求返回给前端的行为。

此外，函数还可以返回一个ModelAndView对象，表示渲染一个视图，比方说错误页面。 不过，在前后端分离为主流架构的今天，这个很少用了。如果函数返回的视图为空，则表示不需要视图。

1.2. 使用示例

来看一个例子：

@Component
@Slf4j
public class CustomHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        Method method = null;
        if (handler != null && handler instanceof HandlerMethod) {
            method = ((HandlerMethod) handler).getMethod();
        }

        log.error("[{}] system error", method, ex);
        ResponseDTO response = ResponseDTO.builder()
        .errorCode(ErrorCode.SYSTEM_ERROR)
        .build();
        byte[] bytes = JSON.toJSONString(response).getBytes(StandardCharsets.UTF_8));
        try {
            FileCopyUtils.copy(bytes, response.getOutputStream());
        } catch (IOException e) {
            log.error("error", e);
            throw new RuntimeException(e);
        }
        return new ModelAndView();
    }
}

逻辑很显然，在发生异常时，将ResponseDTO序列化为json给前端。

1.3. Controller局部异常处理

1.3.1. 使用示例

这种异常处理只局部于某个Controller内，如：

@Controller
@Slf4j
@RequestMapping("/api/demo")
public class DemoController {

    @ExceptionHandler(Exception.class)
    @ResponseBody
    public ResponseDTO<?> exceptionHandler(Exception e) {
        log.error("[{}] system error", e);
        return ResponseDTO.builder()
        .errorCode(ErrorCode.SYSTEM_ERROR)
        .build();
    }
}

  1. 所有Controller方法（即被RequestMapping注解的方法）抛出的异常，会被该异常处理方法处理。
  2. 使用上，在Controller内部，用@ExceptionHandler注解的方法，就会作为该Controller内部的异常处理方法。
  3. 并且，它的参数中可以注入如WebRequest、NativeWebRequest等，用来拿到请求相关的数据。
  4. 它可以返回String代表一个view名称，也可以返回一个对象并且用@ResponseBody修饰，由框架的其它机制帮你序列化。

此外，它还能够对异常类型进行细粒度的控制，通过注解可以有选择的指定异常处理方法应用的异常类型：

@ExceptionHandler({BusinessException.class, DataBaseError.class })

虽然说全局异常处理HandlerExceptionResolver通过条件判断也能做到， 但是使用这种注解方式明显更具有可读性。

1.3.2. 一个问题

刚才说到异常处理函数可以用@ResponseBody修饰，就像一般的Controller方法一样。

然而，非常遗憾的是，如果使用自定义的HandlerMethodReturnValueHandler，却不生效。 比如：

@ExceptionHandler(Exception.class)
@JsonResponse
public ResponseDTO<?> exceptionHandler(Exception e) {
    log.error("[{}] system error", e);
    return ResponseDTO.builder()
    .errorCode(ErrorCode.SYSTEM_ERROR)
    .build();
}

不知道是我的使用姿势不对，还是什么情况？各种google后无果。

所以，目前的解决方案是，如果能够控制@JsonResponse注解相关的定义代码，将处理返回值这部分逻辑抽取出来，然后在异常处理函数中手动调用。

1.4. ControllerAdvice

1.4.1. 使用示例

刚才介绍的是Controller局部的异常处理，用于处理该Controller内部的特有的异常处理十分有用。 首先，定义一个存放异常处理函数的类，并使用@ControllerAdvice修饰。

@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})
public class ExceptionAdvice {

    @ExceptionHandler(ErrorCodeWrapperException.class)
    @ResponseBody
    public ResponseDTO<?> exceptionHandler(ErrorCodeWrapperException e) {
        if ((errCodeException.getErrorCode().equals(ErrorCode.SYSTEM_ERROR))) {
            log.error(e);
        }
        return ResponseDTO.ofErroCodeWrapperException(errCodeException);
    }
}

@ExceptionHanlder修饰的方法的写法和Controller内的异常处理函数写法是一样的。

1.4.2. 控制生效的Controller范围

注意到，我是这样编写注解的：

@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})

它用来限定这些异常处理函数起作用的Controller的范围。如果不写，则默认对所有Controller有效。

这也是ControllerAdvice进行统一异常处理的优点，它能够细粒度的控制该异常处理器针对哪些Controller有效，这样的好处是：

  1. 一个系统里就能够存在不同的异常处理器，Controller也可以有选择的决定使用哪个，更加灵活。
  2. 不同的业务模块可能对异常处理的方式不同，通过该机制就能做到。
  3. 设想一个一开始并未使用全局异常处理的系统，如果直接引入全局范围内生效的全局异常处理，势必可能会改变已有Controller的行为，有侵入性。 也就是说，如果不控制生效范围，即默认对所有Controller生效。如果控制生效范围，则默认对所有Controller不生效，降低侵入性。

如刚才示例中的例子，只针对实现了GlobalExceptionHandlerMixin接口的类有效：

@Controller
@Slf4j
@RequestMapping("/api/demo")
public class DemoController implements GlobalExceptionHandlerMixin {
}

ControllerAdvice支持的限定范围：

  1. 按注解：@ControllerAdvice(annotations = RestController.class)
  2. 按包名：@ControllerAdvice("org.example.controllers")
  3. 按类型：@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})

2. 总结

以上几种方式是Spring专门为异常处理设计的机制。 就我个人而言，由于ControllerAdvice具有更细粒度的控制能力，所以我更偏爱于在系统中使用ControllerAdvice进行统一异常处理。 除了用异常来传递系统中的意外错误，也会用它来传递处于接口行为一部分的业务错误。 这也是异常的优点之一，如果接口的实现比较复杂，分多层函数实现，如果直接传递错误码，那么到Controller的路径上的每一层函数都需要检查错误码，退回到了C语言那种可怕的“写一行语句检查一下错误码”的模式。

当然，理论上，任何能够给Controller加切面的机制都能变相的进行统一异常处理。比如：

  1. 在拦截器内捕获Controller的异常，做统一异常处理。
  2. 使用Spring的AOP机制，做统一异常处理。
文章目录
  1. 1. 1. 全局异常处理
    1. 1.1. 1.1. HandlerExceptionResolver接口
    2. 1.2. 1.2. 使用示例
    3. 1.3. 1.3. Controller局部异常处理
      1. 1.3.1. 1.3.1. 使用示例
      2. 1.3.2. 1.3.2. 一个问题
    4. 1.4. 1.4. ControllerAdvice
      1. 1.4.1. 1.4.1. 使用示例
      2. 1.4.2. 1.4.2. 控制生效的Controller范围
  2. 2. 2. 总结