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

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

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

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

實現HandlerExceptionResolver接口。

將實現類作為Spring Bean，這樣Spring就能掃描到它并作為全局異常處理器加載。

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

此外，函數還可以返回一個ModelAndView對象，表示渲染一個視圖，比方說錯誤頁面。
不過，在前后端分離為主流架構的今天，這個很少用了。如果函數返回的視圖為空，則表示不需要視圖。

1.2. 使用示例

來看一個例子：

@Component @Slf4j public?class?CustomHandlerExceptionResolver?implements?HandlerExceptionResolver?{@Overridepublic?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)@ResponseBodypublic?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)@ResponseBodypublic?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})

2. 總結

---

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

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

在攔截器內捕獲Controller的異常，做統一異常處理。

使用Spring的AOP機制，做統一異常處理。

總結

以上是生活随笔為你收集整理的Spring 中的统一异常处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。