Spring 中的统一异常处理
发布于 5 天前 作者 yan 28 次浏览

点击上方“芋道源码”,选择“设为星标

做积极的人,而不是积极废人!

源码精品专栏

来源:http://rrd.me/ewU7R

    1. 全局异常处理
  • 1.1. HandlerExceptionResolver接口

  • 1.2. 使用示例

  • 1.3. Controller局部异常处理

  • 1.4. ControllerAdvice

    1. 总结

在具体的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](/user/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](/user/param) request current HTTP request
     * [@param](/user/param) response current HTTP response
     * [@param](/user/param) handler the executed handler, or {[@code](/user/code) null} if none chosen at the
     * time of the exception (for example, if multipart resolution failed)
     * [@param](/user/param) ex the exception that got thrown during handler execution
     * [@return](/user/return) a corresponding ModelAndView to forward to,
     * or {[@code](/user/code) null} for default processing
     */
    ModelAndView resolveException(
            HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex);
}

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

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

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

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

1.2. 使用示例

来看一个例子:

[@Component](/user/Component)
[@Slf4j](/user/Slf4j)
public class CustomHandlerExceptionResolver implements HandlerExceptionResolver {

    [@Override](/user/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](/user/Controller)
[@Slf4j](/user/Slf4j)
[@RequestMapping](/user/RequestMapping)("/api/demo")
public class DemoController {

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

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

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

[@ExceptionHandler](/user/ExceptionHandler)({BusinessException.class, DataBaseError.class })

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

1.3.2. 一个问题

刚才说到异常处理函数可以用 [@ResponseBody](/user/ResponseBody) 修饰,就像一般的Controller方法一样。

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

[@ExceptionHandler](/user/ExceptionHandler)(Exception.class)
[@JsonResponse](/user/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](/user/ControllerAdvice) 修饰。

[@ControllerAdvice](/user/ControllerAdvice)(assignableTypes = {GlobalExceptionHandlerMixin.class})
public class ExceptionAdvice {

    [@ExceptionHandler](/user/ExceptionHandler)(ErrorCodeWrapperException.class)
    [@ResponseBody](/user/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](/user/ControllerAdvice)(assignableTypes = {GlobalExceptionHandlerMixin.class})

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

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

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

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

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

ControllerAdvice支持的限定范围:

  • 按注解: [@ControllerAdvice](/user/ControllerAdvice)(annotations = RestController.class)
  • 按包名: [@ControllerAdvice](/user/ControllerAdvice)("org.example.controllers")
  • 按类型: [@ControllerAdvice](/user/ControllerAdvice)(assignableTypes = {ControllerInterface.class, AbstractController.class})

2. 总结

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

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

  • 在拦截器内捕获Controller的异常,做统一异常处理。
  • 使用Spring的AOP机制,做统一异常处理。


欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式, 长按下方二维码噢

已在知识星球更新源码解析如下:

如果你喜欢这篇文章,喜欢,转发。

生活很美好,明天见(。・ω・。)ノ♡

回到顶部