全局异常处理

Mon, 01 Jan 0001 00:00:00 +0000

全局异常处理

在项目开发过程中，不管是对底层数据库的操作过程，还是业务层的处理过程，还是控制层的处理过程，都不可避免会遇到各种可预知的、不可预知的异常需要处理。如果对每个过程都单独作异常处理，那系统的代码耦合度会变得很高，此外，开发工作量也会加大而且不好统一，这也增加了代码的维护成本。

针对这种实际情况，我们需要将所有类型的异常处理从各处理过程解耦出来，这样既保证了相关处理过程的功能单一，也实现了异常信息的统一处理和维护。同时，我们也不希望直接把异常抛给用户，应该对异常进行处理，对错误信息进行封装，然后返回一个友好的信息给用户。

定义返回的统一 json 结构

前端或者其他服务请求本服务的接口时，该接口需要返回对应的 json 数据，一般该服务只需要返回请求着需要的参数即可，但是在实际项目中，我们需要封装更多的信息，比如状态码 code、相关信息 msg 等等，这一方面是在项目中可以有个统一的返回结构，整个项目组都适用，另一方面是方便结合全局异常处理信息，因为异常处理信息中一般我们需要把状态码和异常内容反馈给调用方。

public class JsonResult {
 /**
 * 异常码
 */
 protected String code;
 /**
 * 异常信息
 */
 protected String msg;

 public JsonResult() {
 this.code = "200";
 this.msg = "操作成功";
 }

 public JsonResult(String code, String msg) {
 this.code = code;
 this.msg = msg;
 }
 // get set
}

处理系统异常

新建一个 GlobalExceptionHandler 全局异常处理类，然后加上 @ControllerAdvice 注解即可拦截项目中抛出的异常，如下：

@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
 // 打印log
 private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
 // ……
}

我们点开 @ControllerAdvice 注解可以看到，@ControllerAdvice 注解包含了 @Component 注解，说明在 Spring Boot 启动时，也会把该类作为组件交给 Spring 来管理。除此之外，该注解还有个 basePackages 属性，该属性是用来拦截哪个包中的异常信息，一般我们不指定这个属性，我们拦截项目工程中的所有异常。@ResponseBody 注解是为了异常处理完之后给调用方输出一个 json 格式的封装数据。

Spring Boot 中很简单，在方法上通过 @ExceptionHandler 注解来指定具体的异常，然后在方法中处理该异常信息，最后将结果通过统一的 json 结构体返回给调用者。

处理参数缺失异常

在前后端分离的架构中，前端请求后台的接口都是通过 rest 风格来调用，有时候，比如 POST 请求需要携带一些参数，但是往往有时候参数会漏掉。另外，在微服务架构中，涉及到多个微服务之间的接口调用时，也可能出现这种情况，此时我们需要定义一个处理参数缺失异常的方法，来给前端或者调用方提示一个友好信息。

参数缺失的时候，会抛出 HttpMessageNotReadableException，我们可以拦截该异常，做一个友好处理，如下：


/**
* 缺少请求参数异常
* @param ex HttpMessageNotReadableException
* @return
*/
@ExceptionHandler(MissingServletRequestParameterException.class)
@ResponseStatus(value = HttpStatus.BAD_REQUEST)
public JsonResult handleHttpMessageNotReadableException(
 MissingServletRequestParameterException ex) {
 logger.error("缺少请求参数，{}", ex.getMessage());
 return new JsonResult("400", "缺少必要的请求参数");
}

我们来写个简单的 Controller 测试一下该异常，通过 POST 请求方式接收两个参数：姓名和密码。

@RestController
@RequestMapping("/exception")
public class ExceptionController {
 private static final Logger logger = LoggerFactory.getLogger(ExceptionController.class);
 @PostMapping("/test")
 public JsonResult test(@RequestParam("name") String name,
 @RequestParam("pass") String pass) {
 logger.info("name：{}", name);
 logger.info("pass：{}", pass);
 return new JsonResult();
 }
}

调用的时候，只传姓名，不传密码，就会抛缺少参数异常，该异常被捕获之后，就会进入我们写好的逻辑，给调用方返回一个友好信息。

处理空指针异常

空指针异常是开发中司空见惯的东西了，一般发生的地方有哪些呢？先来聊一聊一些注意的地方，比如在微服务中，经常会调用其他服务获取数据，这个数据主要是 json 格式的，但是在解析 json 的过程中，可能会有空出现，所以我们在获取某个 jsonObject 时，再通过该 jsonObject 去获取相关信息时，应该要先做非空判断。

还有一个很常见的地方就是从数据库中查询的数据，不管是查询一条记录封装在某个对象中，还是查询多条记录封装在一个 List 中，我们接下来都要去处理数据，那么就有可能出现空指针异常，因为谁也不能保证从数据库中查出来的东西就一定不为空，所以在使用数据时一定要先做非空判断。对空指针异常的处理很简单，和上面的逻辑一样，将异常信息换掉即可。如下：

@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
 private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
 /**
 * 空指针异常
 * @param ex NullPointerException
 * @return
 */
 @ExceptionHandler(NullPointerException.class)
 @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)
 public JsonResult handleTypeMismatchException(NullPointerException ex) {
 logger.error("空指针异常，{}", ex.getMessage());
 return new JsonResult("500", "空指针异常了");
 }
}

这个我就不测试了，代码中 ExceptionController 有个 testNullPointException 方法，模拟了一个空指针异常，我们在浏览器中请求一下对应的 url 即可看到返回的信息：

{ "code": "500", "msg": "空指针异常了" }

一劳永逸？

当然了，异常很多，比如还有 RuntimeException，数据库还有一些查询或者操作异常等等。由于 Exception 异常是父类，所有异常都会继承该异常，所以我们可以直接拦截 Exception 异常，一劳永逸：

@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
 private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
 /**
 * 系统异常 预期以外异常
 * @param ex
 * @return
 */
 @ExceptionHandler(Exception.class)
 @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)
 public JsonResult handleUnexpectedServer(Exception ex) {
 logger.error("系统异常：", ex);
 return new JsonResult("500", "系统发生异常，请联系管理员");
 }
}

但是项目中，我们一般都会比较详细的去拦截一些常见异常，拦截 Exception 虽然可以一劳永逸，但是不利于我们去排查或者定位问题。实际项目中，可以把拦截 Exception 异常写在 GlobalExceptionHandler 最下面，如果都没有找到，最后再拦截一下 Exception 异常，保证输出信息友好。

拦截自定义异常

在实际项目中，除了拦截一些系统异常外，在某些业务上，我们需要自定义一些业务异常，比如在微服务中，服务之间的相互调用很平凡，很常见。要处理一个服务的调用时，那么可能会调用失败或者调用超时等等，此时我们需要自定义一个异常，当调用失败时抛出该异常，给 GlobalExceptionHandler 去捕获。

定义异常信息

由于在业务中，有很多异常，针对不同的业务，可能给出的提示信息不同，所以为了方便项目异常信息管理，我们一般会定义一个异常信息枚举类。比如：

/**
 * 业务异常提示信息枚举类

 */
public enum BusinessMsgEnum {
 /** 参数异常 */
 PARMETER_EXCEPTION("102", "参数异常!"),
 /** 等待超时 */
 SERVICE_TIME_OUT("103", "服务调用超时！"),
 /** 参数过大 */
 PARMETER_BIG_EXCEPTION("102", "输入的图片数量不能超过50张!"),
 /** 500 : 一劳永逸的提示也可以在这定义 */
 UNEXPECTED_EXCEPTION("500", "系统发生异常，请联系管理员！");
 // 还可以定义更多的业务异常
 /**
 * 消息码
 */
 private String code;
 /**
 * 消息内容
 */
 private String msg;
 private BusinessMsgEnum(String code, String msg) {
 this.code = code;
 this.msg = msg;
 }
 // set get方法
}

拦截自定义异常

然后我们可以定义一个业务异常，当出现业务异常时，我们就抛这个自定义的业务异常即可。比如我们定义一个 BusinessErrorException 异常，如下：

/**
 * 自定义业务异常

 */
public class BusinessErrorException extends RuntimeException {

 private static final long serialVersionUID = -7480022450501760611L;
 /**
 * 异常码
 */
 private String code;
 /**
 * 异常提示信息
 */
 private String message;
 public BusinessErrorException(BusinessMsgEnum businessMsgEnum) {
 this.code = businessMsgEnum.code();
 this.message = businessMsgEnum.msg();
 }
 // get set方法
}

在构造方法中，传入我们上面自定义的异常枚举类，所以在项目中，如果有新的异常信息需要添加，我们直接在枚举类中添加即可，很方便，做到统一维护，然后再拦截该异常时获取即可。

@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
 private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
 /**
 * 拦截业务异常，返回业务异常信息
 * @param ex
 * @return
 */
 @ExceptionHandler(BusinessErrorException.class)
 @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)
 public JsonResult handleBusinessError(BusinessErrorException ex) {
 String code = ex.getCode();
 String message = ex.getMessage();
 return new JsonResult(code, message);
 }
}

在业务代码中，我们可以直接模拟一下抛出业务异常，测试一下：

@RestController
@RequestMapping("/exception")
public class ExceptionController {
 private static final Logger logger = LoggerFactory.getLogger(ExceptionController.class);
 @GetMapping("/business")
 public JsonResult testException() {
 try {
 int i = 1 / 0;
 } catch (Exception e) {
 throw new BusinessErrorException(BusinessMsgEnum.UNEXPECTED_EXCEPTION);
 }
 return new JsonResult();
 }
}

运行一下项目，测试一下，返回 json 如下，说明我们自定义的业务异常捕获成功：

{ "code": "500", "msg": "系统发生异常，请联系管理员！" }

重试机制

Mon, 01 Jan 0001 00:00:00 +0000

Spring 重试机制

如今，Spring Retry 是一个独立的包了(早期是 Spring Batch 的一部分)，下面是使用 Spring Retry 框架进行重试的几个重要步骤。首先加入 Spring Retry 依赖包

<dependency>
 <groupId>org.springframework.retry</groupId>
 <artifactId>spring-retry</artifactId>
 <version>1.1.2.RELEASE</version>
</dependency>

然后在应用中包含 main()方法的类或者在包含@Configuration 的类上加上@EnableRetry 注解，最后在想要进行重试的方法(可能发生异常)上加上@Retryable 注解：

@Retryable(maxAttempts=5,backoff = @Backoff(delay = 3000))
public void retrySomething() throws Exception{
 logger.info("printSomething{} is called");
 thrownew SQLException();
}

在上面这个案例当中的重试策略就是重试 5 次，每次延时 3 秒。详细的使用文档看这里，它的主要配置参数有下面这样几个。其中 exclude、include、maxAttempts、value 几个属性很容易理解，比较看不懂的是 backoff 属性，它也是个注解，包含 delay、maxDelay、multiplier、random 四个属性。

**delay：**如果不设置的话默认是 1 秒
**maxDelay：**最大重试等待时间
**multiplier：**用于计算下一个延迟时间的乘数(大于 0 生效)
**random：**随机重试等待时间(一般不用)

Spring Retry 的优点很明显：

属于 Spring 大生态，使用起来不会太生硬；
只需要在需要重试的方法上加上注解并配置重试策略属性就好，不需要太多侵入代码。

但同时也存在两个主要不足：

第一，由于 Spring Retry 用到了 Aspect 增强，所以就会有使用 Aspect 不可避免的坑——方法内部调用，如果被 @Retryable 注解的方法的调用方和被调用方处于同一个类中，那么重试将会失效；
第二，Spring 的重试机制只支持对异常进行捕获，而无法对返回值进行校验判断重试。如果想要更灵活的重试策略可以考虑使用 Guava Retry，也是一个不错的选择。

异常处理 | Next-gen Tech Edu

全局异常处理

全局异常处理

定义返回的统一 json 结构

处理系统异常

处理参数缺失异常

处理空指针异常

一劳永逸？

拦截自定义异常

定义异常信息

拦截自定义异常

重试机制

Spring 重试机制