知識星球（點選上方公眾號，可快速關註）
來源：Frapples ，
frapples.github.io/articles/2018-09-01-ecbc.html
在具體的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.
*
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})
總結
以上幾種方式是 Spring 專門為異常處理設計的機制。就我個人而言，由於 ControllerAdvice 具有更細粒度的控制能力，所以我更偏愛於在系統中使用 ControllerAdvice 進行統一異常處理。除了用異常來傳遞系統中的意外錯誤，也會用它來傳遞處於介面行為一部分的業務錯誤。這也是異常的優點之一，如果介面的實現比較複雜，分多層函式實現，如果直接傳遞錯誤碼，那麼到 Controller 的路徑上的每一層函式都需要檢查錯誤碼，退回到了C語言那種可怕的“寫一行陳述句檢查一下錯誤碼”的樣式。
當然，理論上，任何能夠給 Controller 加切麵的機制都能變相的進行統一異常處理。比如：
-
在攔截器內捕獲 Controller 的異常，做統一異常處理。
-
使用 Spring 的 AOP 機制，做統一異常處理。
【關於投稿】
如果大家有原創好文投稿，請直接給公號傳送留言。
① 留言格式：
【投稿】+《 文章標題》+ 文章連結
② 示例：
【投稿】《不要自稱是程式員，我十多年的 IT 職場總結》：http://blog.jobbole.com/94148/
③ 最後請附上您的個人簡介哈~
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
