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修飾，由框架的其它機制幫你序列化。

此外，它還能夠對異常類型進行細粒度的控制，通過註解可以有選擇的指定異常處理方法應用的異常類型：

@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. ControllerAdvice

1.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範圍

注意到，我是這樣編寫註解的：

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