Spring中异常的统一的处理方式

在具体的SSM项目开发中，由于Controller层为处于请求处理的最顶层，再往上就是框架代码的。
因此，肯定需要在Controller捕获所有异常，并且做适当处理，返回给前端一个友好的错误码。
不过，Controller一多，我们发现每个Controller里都有大量重复的、冗余的异常处理代码，导致很难看。
能否将这些重复的部分抽取出来，这样保证Controller层更专注于业务逻辑的处理，
同时能够使得异常的处理有一个统一的控制中心点。

全局异常处理
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);
}

使用全局异常处理器只需要两步：
实现HandlerExceptionResolver接口。
将实现类作为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局部异常处理
这种异常处理只局部于某个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();
    }
}

所有Controller方法（即被RequestMapping注解的方法）抛出的异常，会被该异常处理方法处理。
使用上，在Controller内部，用@ExceptionHandler注解的方法，就会作为该Controller内部的异常处理方法。
并且，它的参数中可以注入如WebRequest、NativeWebRequest等，用来拿到请求相关的数据。
它可以返回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();
}

1.4.2. 控制生效的Controller范围

@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})

它用来限定这些异常处理函数起作用的Controller的范围。如果不写，则默认对所有Controller有效。
这也是ControllerAdvice进行统一异常处理的优点，它能够细粒度的控制该异常处理器针对哪些Controller有效，这样的好处是：
一个系统里就能够存在不同的异常处理器，Controller也可以有选择的决定使用哪个，更加灵活。
不同的业务模块可能对异常处理的方式不同，通过该机制就能做到。
设想一个一开始并未使用全局异常处理的系统，如果直接引入全局范围内生效的全局异常处理，势必可能会改变已有Controller的行为，有侵入性。
也就是说，如果不控制生效范围，即默认对所有Controller生效。如果控制生效范围，则默认对所有Controller不生效，降低侵入性。
如刚才示例中的例子，只针对实现了GlobalExceptionHandlerMixin接口的类有效：

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

ControllerAdvice支持的限定范围：

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

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

转载某大神的文章，如果涉及侵权，请大神通知，必删除

Spring中异常的统一的处理方式

猜你喜欢