Spring中的统一异常处理

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

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

欢迎学Java和大数据的朋友们加入java架构交流： 855835163

群内提供免费的架构资料还有：Java工程化、高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring，MyBatis，Netty源码分析和大数据等多个知识点高级进阶干货的免费直播讲解 可以进来一起学习交流哦

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.

*

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局部异常处理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();

}

}

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

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

1@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. ControllerAdvice1.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范围

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

1@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})

总结a

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

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

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

欢迎学Java和大数据的朋友们加入java架构交流： 855835163

群内提供免费的架构资料还有：Java工程化、高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring，MyBatis，Netty源码分析和大数据等多个知识点高级进阶干货的免费直播讲解 可以进来一起学习交流哦

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!