spring中的統一異常處理

神一樣的程式設計發表於2018-09-21
Spring

在具體的SSM專案開發中，由於Controller層為處於請求處理的最頂層，再往上就是框架程式碼的。
因此，肯定需要在Controller捕獲所有異常，並且做適當處理，返回給前端一個友好的錯誤碼。

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

1. 全域性異常處理

1.1. HandlerExceptionResolver介面

12345678910111213141516171819複製程式碼
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. 使用示例

來看一個例子：

12345678910111213141516171819202122232425複製程式碼
@Component@Slf4jpublic 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內，如：

1234567891011121314複製程式碼
@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，卻不生效。
比如：

12345678複製程式碼
@ExceptionHandler(Exception.class)@JsonResponsepublic 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修飾。

123456789101112複製程式碼
@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介面的類有效：

12345複製程式碼
@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})

2. 總結

以上幾種方式是Spring專門為異常處理設計的機制。
就我個人而言，由於ControllerAdvice具有更細粒度的控制能力，所以我更偏愛於在系統中使用ControllerAdvice進行統一異常處理。
除了用異常來傳遞系統中的意外錯誤，也會用它來傳遞處於介面行為一部分的業務錯誤。
這也是異常的優點之一，如果介面的實現比較複雜，分多層函式實現，如果直接傳遞錯誤碼，那麼到Controller的路徑上的每一層函式都需要檢查錯誤碼，退回到了C語言那種可怕的“寫一行語句檢查一下錯誤碼”的模式。

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

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


相關文章