本文首发于稀土掘金：全局异常 @ControllerAdvice 该怎么写，该账号即为本人账号，非搬运。
问题由来
很多小伙伴刚进公司做项目的时候，会看到项目里面有一个@ControllerAdvice标记的类，整个类的编码结构大概是这样子：
@Slf4j
@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
@ExceptionHandler(MyException.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public MyExceptionResponse myException(MyException e) {
//记录日志
log.error("自定义的异常：" + e.getMessage());
//其他处理逻辑。。。。
//返回结果
MyExceptionResponse response = new MyExceptionResponse(1001, "自定义的异常：" + e.getMessage());
return response;
}
@ExceptionHandler(Exception.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public MyExceptionResponse exception(Exception e) {
//记录日志
log.error("exception异常：" + e.getMessage());
//其他处理逻辑。。。。
//返回结果
MyExceptionResponse response = new MyExceptionResponse(1002, "exception异常：" + e.getMessage());
return response;
}
}
其实你随便在网上搜一下@ControllerAdvice或者@ExceptionHandler，就知道这个是统一的全局异常处理，不过你有没有想过，我们为什么需要统一的全局异常处理，以及他的编码结构为啥发展成了上面的样子。
为什么要处理异常
为什么需要处理异常，因为异常是不可避免的，程序总是可能发生异常，所以我们需要处理异常，如果你就是不编写处理异常的代码，程序里面发生的异常最终会抛给spring，而spring其实是提供了异常处理的，也就是你不处理异常，异常就由spring来处理，那么spring处理异常的结果就是，你会在浏览器看到如下界面：
如果你点开F12去看，会看到返回的响应是这样的：
其中Content-Type是text/html，说明spring确实给你返回了一个html界面。
如果你是使用postman、idea的http client这种测试工具，会得到类似这样的结果：
这两种返回结果都是存在的，spring会根据客户端类型来判断是返回html界面还是返回一个json对象。
然而，这两种结果给到前端都是不合适的，一方面是用户体验不好，用户看不懂。另一方面即使用户给你反馈这样的结果，作为程序员的你也看不出来哪里出错了。这里说明一下，系统抛出的异常（包括RuntimeException甚至Exception），其实是带有具体信息的，只是这些异常抛给spring后，spring没有返回具体内容，而是返回上面这些东西，也就是spring把具体信息给隐藏了，只返回了一些静态的默认内容。
因为spring默认返回的结果不够好，所以我们要自定义处理异常的逻辑， 而代码的调用顺序是@Controller->@Service->@Mapper，如果想要捕获所有的异常，就得在最外层进行捕获，也就是在@Controller进行捕获，于是你会写出类似这样的代码：
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/{id}")
public ResponseEntity queryById(@PathVariable("id") Long id) {
try {
//执行业务逻辑
User user = userService.queryById(id);
//返回结果给前端
HttpStatus httpStatus = HttpStatus.OK;
ResponseEntity<User> responseEntity = new ResponseEntity<>(user, httpStatus);
return responseEntity;
} catch (Exception e) {
String msg = "查询用户信息异常，id：" + id;
//记录日志
log.error(msg);
//返回异常信息给前端
HttpStatus httpStatus = HttpStatus.INTERNAL_SERVER_ERROR;
ResponseEntity<String> responseEntity = new ResponseEntity<>(msg, httpStatus);
return responseEntity;
}
}
@PostMapping("/add")
public ResponseEntity addUser(@RequestBody User user) {
try {
//执行业务逻辑
User user = userService.addUser(user);
//返回结果给前端
HttpStatus httpStatus = HttpStatus.OK;
ResponseEntity<User> responseEntity = new ResponseEntity<>(user, httpStatus);
return responseEntity;
} catch (Exception e) {
String msg = "新增用户信息异常，用户信息：" + JSON.toJSONString(user);
//记录日志
log.error(msg);
//返回异常信息给前端
HttpStatus httpStatus = HttpStatus.INTERNAL_SERVER_ERROR;
ResponseEntity<String> responseEntity = new ResponseEntity<>(msg, httpStatus);
return responseEntity;
}
}
}
仔细琢磨一下你会发现这种写法非常难受，首先你需要在每一个@Controller类的每一个方法里面都写上try{}catch(){}块，这种重复性就不是我们能接受的。其次执行正常和异常的返回数据结构是不一样的，执行正常的时候一般返回当前业务对应的JavaBean，比如上面例子的User，执行异常的时候不可能返回User，取而代之的是要想办法把异常信息返回给前端，这就导致方法的返回值得定义成ResponseEntity，然后你每次都要去装填ResponseEntity对象。
为了避免如此麻烦的写法，自spring3.2开始，给我们提供了@ControllerAdvice注解来进行统一的异常处理，他的执行效果是这样的：
如果你使用@ControllerAdvice标记了一个类，那么在程序里发生的所有异常，spring都会将他传给@ControllerAdvice标记的那个类里面，让你自己处理异常。该注解基本用法如下：
@Slf4j
@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
@ExceptionHandler(RuntimeException.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public String runtimeException(RuntimeException e) {
//记录日志
log.error("runtime异常：" + e.getMessage());
//返回结果
return "runtime异常：" + e.getMessage();
}
@ExceptionHandler(Exception.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public String exception(Exception e) {
//记录日志
log.error("exception异常：" + e.getMessage());
//返回结果
return "exception异常：" + e.getMessage();
}
}
说明：
- 首先你不需要在每一个@Controller的每一个@RequestMapping方法里都写try{}catch(){}代码块了，spring会将发生的异常传递到@ControllerAdvice类里面的@ExceptionHandler方法，具体传递到哪个方法，是由异常的类型来进行划分的，也就是同一类型的异常执行相同的处理逻辑，像上面的例子就是将Exception下面的RutimeException做单独处理，其余的都归到Exception来处理。
- 其次你的@Controller里的@RequestMapping方法的返回值类型不再需要写ResponseEntity了，可以写具体业务对应的JavaBean，因为发生异常时的返回值类型由@ExceptionHandler所在方法的返回值定义了。
- @ControllerAdvice的用法和@Controller有点像，比如都可以在类上面添加@ResponseBody，让类里面的方法可以返回字符串或直接返回JavaBean。
- 最后说下@ResponseStatus，这个注解是用来设置http响应码的，这里我设置的“HttpStatus.INTERNAL_SERVER_ERROR”会返回500给前端，如果你不设置的话，会返回默认值200。
以上是spring提供的统一异常处理@ControllerAdvice的基本用法，不过他和文章开头的代码还是有些区别，我们来看看这段代码还有什么可以优化一下。
自定义业务异常类
就异常的来源来说，除了系统抛出的异常，其实我们自己也可以抛出异常，比如在业务执行过程中发现不对的时候，会通过抛异常的方式让程序终止：
@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id) {
User user = userService.queryById(id);
if(user == null){
throw new RuntimeException("该用户不存在");
}
//可能还有其他的业务逻辑。。。。
//最终返回结果
return user;
}
其实这样子抛出的异常，也可以被上面“基本用法”当中的@ControllerAdvice接收和处理，但是这种异常情况，其实是在我们的预期范围内的，是在我们的预期下主动抛出的，是一种“业务异常”，他和系统抛出的RuntimeException不一样，像空指针、数组越界之类的（他们都是RuntimeException的子类）他们表示你代码写的有问题，代码不够完善，而我们自己抛出的异常，是一种在预期范围内的业务逻辑上的错误，我们希望把他们给区分开来，于是会为这种业务异常单独定义一个类：
public class MyException extends RuntimeException {
private String errorMsg;
public MyException() {
}
//省略getter、setter等方法
}
然后在抛异常的时候抛出自定义类的异常：
@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id) {
User user = userService.queryById(id);
if(user == null){
throw new MyException("该用户不存在");
}
//可能还有其他的业务逻辑。。。。
//最终返回结果
return user;
}
于是@ControllerAdvice里面的写法会变成这样：
@Slf4j
@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
//主要改动点在这里，把RuntimeException.class改成了MyException.class
@ExceptionHandler(MyException.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public String myException(MyException e) {
//记录日志
log.error("自定义的异常：" + e.getMessage());
//返回结果
return "自定义的异常：" + e.getMessage();
}
@ExceptionHandler(Exception.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public String exception(Exception e) {
//记录日志
log.error("exception异常：" + e.getMessage());
//返回结果
return "exception异常：" + e.getMessage();
}
}
其实就是把原来的RuntimeException改成了自定义的异常，另外仍然由Exception处理自定义异常之外的所有异常。
统一返回给前端的数据结构
接下来的一个优化就是，统一返回给前端的数据结构，上面代码当中返回给前端的都是一个字符串，用来描述异常信息，但其实更好的做法是像@Controller里的接口那样，返回一个JavaBean，甚至是所有类型的异常都返回一个格式统一的JavaBean，于是我们会定义一个用于表示返回值数据结构的类：
public class MyExceptionResponse implements Serializable {
//其实这个code不是必须的，
//不过下面的errorMsg就比较有必要，你总得有一个字符串来描述你的异常信息吧
private int code;
private String errorMsg;
public MyExceptionResponse() {
}
//其他的什么构造方法、getter、setter方法就不写了，大家能看明白就行
}
最终得到的@ControllerAdvice就变成下面这样：
@Slf4j
@ControllerAdvice
@ResponseBody
public class GlobalExceptionHandler {
@ExceptionHandler(MyException.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public MyExceptionResponse runtimeException(MyException e) {
//记录日志
log.error("自定义的异常：" + e.getMessage());
//其他处理逻辑。。。。
//返回结果
MyExceptionResponse response = new MyExceptionResponse(1001, "自定义的异常：" + e.getMessage());
return response;
}
@ExceptionHandler(Exception.class)
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public MyExceptionResponse exception(Exception e) {
//记录日志
log.error("exception异常：" + e.getMessage());
//其他处理逻辑。。。。
//返回结果
MyExceptionResponse response = new MyExceptionResponse(1002, "exception异常：" + e.getMessage());
return response;
}
}
其他补充
注意一下，@ControllerAdvice是对@Controller进行功能增强，搭配@ExceptionHandler进行全局异常处理只是他其中的一个用法（可以认为异常处理也是一种功能增强），他还可以搭配@InitBinder或者@ModelAttribute实现其他功能，基本都是对@Controller进行增强。
828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
