导言：
为什么要做异常处理： 原因有三： 1、将系统产生的全部异常统一捕获处理。
2、自定义异常需要由全局异常来捕获。
3、JSR303规范的validator参数校验器、参数校验不通过、本身无法使用try…catch
其实对于前后端分离的项目做异常处理是很有必要的 在不出异常的情况下，后端将数据封装成固定格式（也就是R类）返回给前端，方便前端去解析数据 例如如下R类：
@Data
public class R
private Integer code; //编码：1成功，0和其它数字为失败
private String msg; //错误信息
private T data; //数据
private Map map = new HashMap(); //动态数据
public static
R
r.data = object;
r.code = 1;
return r;
}
public static
R
r.data = object;
r.code = 1;
r.msg = msg;
return r;
}
public static
R r = new R();
r.msg = msg;
r.code = 0;
return r;
}
public static
R r = new R();
r.msg = msg;
r.code = 1;
return r;
}
public R
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
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
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机制，通过切面和增强的方式，实现了全局异常处理和数据绑定的功能。
精彩链接
您阅读本篇文章共花了：
发表评论