导言:
为什么要做异常处理:
原因有三:
1、将系统产生的全部异常统一捕获处理。
2、自定义异常需要由全局异常来捕获。
3、JSR303规范的validator参数校验器、参数校验不通过、本身无法使用try…catch
其实对于前后端分离的项目做异常处理是很有必要的
在不出异常的情况下,后端将数据封装成固定格式(也就是R类)返回给前端,方便前端去解析数据
例如如下R类:
@Data
public class R<T> implements Serializable {private Integer code; //编码:1成功,0和其它数字为失败private String msg; //错误信息private T data; //数据private Map map = new HashMap(); //动态数据public static <T> R<T> success(T object) {R<T> r = new R<T>();r.data = object;r.code = 1;return r;}public static <T> R<T> success(String msg,T object) {R<T> r = new R<T>();r.data = object;r.code = 1;r.msg = msg;return r;}public static <T> R<T> error(String msg) {R r = new R();r.msg = msg;r.code = 0;return r;}public static <T> R<T> success(String msg) {R r = new R();r.msg = msg;r.code = 1;return r;}public R<T> add(String key, Object value) {this.map.put(key, value);return this;}}
正常不出异常的情况下根据controller层返回的数据:
controller层
//正常情况@GetMapping("/hhy/1")public R info(){int i = 60/1;return R.success("成功",i);}
请求成功返回给前端数据:
在出异常的情况下(模拟除0异常):
controller层:
//空指针异常@GetMapping("/hhy/2")public R info2(){int i = 60/0;return R.success("成功",i);}
出现异常前端拿不到数据,并且后端报错:
前端:
后端:
这样虽然后端可以知道异常情况,但是前端就难受了,啥也不知道,就知道出错了;
重点来了!!!!!
这里就可以体现全局异常处理器的重要性了;让前端的兄弟好受一点。
实现全局异常处理器捕获异常
举例:异常还是除0 异常:
java.lang.ArithmeticException: / by zero
这里的异常就是ArithmeticException
,异常信息为/ by zero
编写全局异常捕获类:GlobalExceptionHandler
/*** 全局异常捕获*/
@Slf4j
@ControllerAdvice(annotations = {RestController.class, Controller.class})
//只要类的注解上有这些注解。那么发生的异常都能被捕获到
@ResponseBody
public class GlobalExceptionHandler {/*** 处理除0异常捕获* @param exception* @return*/@ExceptionHandler(ArithmeticException.class)//ArithmeticException异常类型通过注解拿到public R<String> exceptionHandler(ArithmeticException exception){log.error(exception.getMessage());//在控制台打印错误信息return R.error(exception.getMessage());}
}
此时在controller层出现ArithmeticException(除0)异常时就会被全局异常处理器捕获到:
后端::相比之前一大串报错,是不是很清爽
前端:
在异常处理器里面已将错误信息封装成返回类R返回给前端
相比之前返回给前端的一大串杂七杂八的,这个是不是超级清爽,并且可以根据code码在前端将错误信息设置警告框
这样前端的兄弟看到信息就知道,嗷嗷 后端出问题了 问题是除0异常,这样就可以安心的去甩锅给后端的哥们了;
实现原理:
想必注意到这个注解:
@ControllerAdvice
(annotations = {RestController.class, Controller.class
})
意思只要类的注解上有这些注解。那么发生的异常都能被捕获到,例如例子中出现的异常的类的注解为:
异常捕获类的
@ResponseBody
注解
当我们在全局异常处理中使用@ResponseBody注解时,它可以将异常信息序列化为JSON或其他格式的字符串,并作为HTTP响应的Body部分返回给客户端。
这就是为什么前端的兄弟能看到如此清爽的返回数据格式:
不加@ResponseBody那就智能看到又臭又长的这个:
@ExceptionHandler
(ArithmeticException.class)
具体拦截类上的@ExceptionHandler注解主要是指定去捕获哪一种异常,这个很好理解
需要拦截捕获哪一类异常就去指定具体的类异常,捕获原理如上;
but··························
那么如果用户在操作的时候,出现一些有违背业务逻辑的情况下,我们也视为操作异常,抛出自定义的异常,返回给前端,然后告诉用户不能这么操作
自定义异常处理
1、首先要编写异常自定义处理类:
CustomException
public class CustomException extends RuntimeException{/*** 自定义业务异常类* @param message*/public CustomException(String message){super(message);log.info(message.toString());}
}
这里将业务层抛出的异常信息捕获到,然后归类为runtime运行时异常,
然后交给全局异常处理器去处理,给前端提供错误信息
2、在全局异常类里面去捕获自定义异常CustomException
/*** 将业务层抛出的异常信息捕获到,然后交给全局异常处理器去处理,给前端提供错误信息* @param exception* @return*/@ExceptionHandler(CustomException.class)//RuntimeException异常类型通过注解拿到public R<String> exceptionCategoryDelete(CustomException exception){log.error(exception.getMessage());//在控制台打印错误信息return R.error(exception.getMessage());}
原理上面已经讲过了,不在赘述
那我们来测试一下,在业务层抛出一个CustomException ,看能不能被全局异常类捕获到:
后端:
前端:
这样我们就可以愉快的解决异常问题了
这里稍稍解释下
@ControllerAdvice注解
@ControllerAdvice注解是基于Spring框架的AOP(面向切面编程)实现的。AOP是一种编程范式,它通过在应用程序运行时,将横跨多个组件的行为进行分离和管理。
在Spring框架中,通过AOP可以将一些通用的横切关注点(比如异常处理、日志记录等)从业务逻辑中剥离出来,并以声明的方式进行集中管理。@ControllerAdvice注解就是利用了AOP的机制,在应用程序的控制器层进行统一的全局异常处理和数据绑定。
底层实现上,@ControllerAdvice注解使用了Spring的核心功能之一:切面(Aspect)和增强(Advice)。通过定义一个带有@ControllerAdvice注解的类,并在其中定义不同类型的增强(比如@ExceptionHandler注解用于异常处理),Spring会在运行时动态生成代理对象,将增强逻辑织入到目标控制器的方法调用中。
总结来说,@ControllerAdvice注解的底层实现基于Spring框架的AOP机制,通过切面和增强的方式,实现了全局异常处理和数据绑定的功能。