Spring中的統一異常處理

在具體的SSM項目開發中，因爲Controller層爲處於請求處理的最頂層，再往上就是框架代碼的。所以，確定須要在Controller捕獲全部異常，而且作適當處理，返回給前端一個友好的錯誤碼。

不過，Controller一多，咱們發現每一個Controller裏都有大量重複的、冗餘的異常處理代碼，非常囉嗦。可否將這些重複的部分抽取出來，這樣保證Controller層更專一於業務邏輯的處理，同時可以使得異常的處理有一個統一的控制中心點。

歡迎學Java和大數據的朋友們加入java架構交流： 855835163

羣內提供免費的架構資料還有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的免費直播講解 能夠進來一塊兒學習交流哦

1. 全局異常處理

1.1. HandlerExceptionResolver接口

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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.      * <p>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); }

使用全局異常處理器只須要兩步：

1. 實現HandlerExceptionResolver接口。
2. 將實現類做爲Spring Bean，這樣Spring就能掃描到它並做爲全局異常處理器加載。

在 resolveException 中實現異常處理邏輯。從參數上，能夠看到，不只可以拿到發生異常的函數和異常對象，還可以拿到 HttpServletResponse對象，從而控制本次請求返回給前端的行爲。

此外，函數還能夠返回一個 ModelAndView 對象，表示渲染一個視圖，比方說錯誤頁面。不過，在先後端分離爲主流架構的今天，這個不多用了。若是函數返回的視圖爲空，則表示不須要視圖。

1.2. 使用示例

來看一個例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

@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 內，如：

1 2 3 4 5 6 7 8 9 10 11 12 13

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

1. 全部 Controller 方法（即被 RequestMapping 註解的方法）拋出的異常，會被該異常處理方法處理。
2. 使用上，在 Controller 內部，用 @ExceptionHandler 註解的方法，就會做爲該Controller內部的異常處理方法。
3. 而且，它的參數中能夠注入如 WebRequest、NativeWebRequest 等，用來拿到請求相關的數據。
4. 它能夠返回 String 表明一個 view 名稱，也能夠返回一個對象而且用 @ResponseBody 修飾，由框架的其它機制幫你序列化。

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

1	@ExceptionHandler({BusinessException.class, DataBaseError.class })

雖說全局異常處理HandlerExceptionResolver經過條件判斷也能作到，可是使用這種註解方式明顯更具備可讀性。

1.3.2. 一個問題

剛纔說到異常處理函數能夠用 @ResponseBody 修飾，就像通常的Controller方法同樣。

然而，很是遺憾的是，若是使用自定義的 HandlerMethodReturnValueHandler，卻不生效。好比：

1 2 3 4 5 6 7 8

@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 修飾。

1 2 3 4 5 6 7 8 9 10 11

@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範圍

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

1	@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})

它用來限定這些異常處理函數起做用的 Controller 的範圍。若是不寫，則默認對全部 Controller 有效。

這也是 ControllerAdvice 進行統一異常處理的優勢，它可以細粒度的控制該異常處理器針對哪些 Controller 有效，這樣的好處是：

1. 一個系統裏就可以存在不一樣的異常處理器，Controller 也能夠有選擇的決定使用哪一個，更加靈活。
2. 不一樣的業務模塊可能對異常處理的方式不一樣，經過該機制就能作到。
3. 設想一個一開始並未使用全局異常處理的系統，若是直接引入全局範圍內生效的全局異常處理，勢必可能會改變已有 Controller 的行爲，有侵入性。
   也就是說，若是不控制生效範圍，即默認對全部 Controller 生效。若是控制生效範圍，則默認對全部 Controller 不生效，下降侵入性。

如剛纔示例中的例子，只針對實現了 GlobalExceptionHandlerMixin 接口的類有效：

1 2 3 4 5

@Controller @Slf4j @RequestMapping("/api/demo")     public class DemoController implements GlobalExceptionHandlerMixin { }

ControllerAdvice 支持的限定範圍

1. 按註解：@ControllerAdvice(annotations = RestController.class)
2. 按包名：@ControllerAdvice("org.example.controllers")
3. 按類型：@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})

總結

以上幾種方式是 Spring 專門爲異常處理設計的機制。就我我的而言，因爲 ControllerAdvice 具備更細粒度的控制能力，因此我更偏心於在系統中使用 ControllerAdvice 進行統一異常處理。除了用異常來傳遞系統中的意外錯誤，也會用它來傳遞處於接口行爲一部分的業務錯誤。這也是異常的優勢之一，若是接口的實現比較複雜，分多層函數實現，若是直接傳遞錯誤碼，那麼到 Controller 的路徑上的每一層函數都須要檢查錯誤碼，退回到了C語言那種可怕的「寫一行語句檢查一下錯誤碼」的模式。

固然，理論上，任何可以給 Controller 加切面的機制都能變相的進行統一異常處理。好比：

1. 在攔截器內捕獲 Controller 的異常，作統一異常處理。
2. 使用 Spring 的 AOP 機制，作統一異常處理。

歡迎學Java和大數據的朋友們加入java架構交流： 855835163

羣內提供免費的架構資料還有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的免費直播講解 能夠進來一塊兒學習交流哦