Spring中統(tǒng)一異常處理示例詳解

2024-07-14 08:42:24

字體：大中小

來源：轉(zhuǎn)載

供稿：網(wǎng)友

前言

系統(tǒng)很多地方都會拋出異常, 而Java的異常體系目標(biāo)就是與邏輯解耦，Spring提供了統(tǒng)一的異常處理注解，用戶只需要在錯(cuò)誤的時(shí)候提示信息即可

在具體的SSM項(xiàng)目開發(fā)中，由于Controller層為處于請求處理的最頂層，再往上就是框架代碼的。

因此，肯定需要在Controller捕獲所有異常，并且做適當(dāng)處理，返回給前端一個(gè)友好的錯(cuò)誤碼。

不過，Controller一多，我們發(fā)現(xiàn)每個(gè)Controller里都有大量重復(fù)的、冗余的異常處理代碼，很是啰嗦。

能否將這些重復(fù)的部分抽取出來，這樣保證Controller層更專注于業(yè)務(wù)邏輯的處理，

同時(shí)能夠使得異常的處理有一個(gè)統(tǒng)一的控制中心點(diǎn)。

下面話不多說了，來一起看看詳細(xì)的介紹吧

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

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

實(shí)現(xiàn)HandlerExceptionResolver接口。
將實(shí)現(xiàn)類作為Spring Bean，這樣Spring就能掃描到它并作為全局異常處理器加載。

在resolveException中實(shí)現(xiàn)異常處理邏輯。

從參數(shù)上，可以看到，不僅能夠拿到發(fā)生異常的函數(shù)和異常對象，還能夠拿到HttpServletResponse對象，從而控制本次請求返回給前端的行為。

此外，函數(shù)還可以返回一個(gè)ModelAndView對象，表示渲染一個(gè)視圖，比方說錯(cuò)誤頁面。

不過，在前后端分離為主流架構(gòu)的今天，這個(gè)很少用了。如果函數(shù)返回的視圖為空，則表示不需要視圖。

1.2. 使用示例

來看一個(gè)例子：

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

邏輯很顯然，在發(fā)生異常時(shí)，將ResponseDTO序列化為json給前端。

1.3. Controller局部異常處理

1.3.1. 使用示例

這種異常處理只局部于某個(gè)Controller內(nèi)，如：

@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內(nèi)部，用@ExceptionHandler注解的方法，就會作為該Controller內(nèi)部的異常處理方法。
并且，它的參數(shù)中可以注入如WebRequest、NativeWebRequest等，用來拿到請求相關(guān)的數(shù)據(jù)。
它可以返回String代表一個(gè)view名稱，也可以返回一個(gè)對象并且用@ResponseBody修飾，由框架的其它機(jī)制幫你序列化。

此外，它還能夠?qū)Ξ惓ｎ愋瓦M(jìn)行細(xì)粒度的控制，通過注解可以有選擇的指定異常處理方法應(yīng)用的異常類型：

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

雖然說全局異常處理HandlerExceptionResolver通過條件判斷也能做到，

但是使用這種注解方式明顯更具有可讀性。

1.3.2. 一個(gè)問題

剛才說到異常處理函數(shù)可以用@ResponseBody修飾，就像一般的Controller方法一樣。

然而，非常遺憾的是，如果使用自定義的HandlerMethodReturnValueHandler，卻不生效。

比如：

@ExceptionHandler(Exception.class)@JsonResponsepublic ResponseDTO<?> exceptionHandler(Exception e) { log.error("[{}] system error", e); return ResponseDTO.builder() .errorCode(ErrorCode.SYSTEM_ERROR) .build();}

不知道是我的使用姿勢不對，還是什么情況？各種google后無果。

所以，目前的解決方案是，如果能夠控制@JsonResponse注解相關(guān)的定義代碼，將處理返回值這部分邏輯抽取出來，然后在異常處理函數(shù)中手動調(diào)用。

1.4. ControllerAdvice

1.4.1. 使用示例

剛才介紹的是Controller局部的異常處理，用于處理該Controller內(nèi)部的特有的異常處理十分有用。

首先，定義一個(gè)存放異常處理函數(shù)的類，并使用@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內(nèi)的異常處理函數(shù)寫法是一樣的。

1.4.2. 控制生效的Controller范圍

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

@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})

它用來限定這些異常處理函數(shù)起作用的Controller的范圍。如果不寫，則默認(rèn)對所有Controller有效。

這也是ControllerAdvice進(jìn)行統(tǒng)一異常處理的優(yōu)點(diǎn)，它能夠細(xì)粒度的控制該異常處理器針對哪些Controller有效，這樣的好處是：

一個(gè)系統(tǒng)里就能夠存在不同的異常處理器，Controller也可以有選擇的決定使用哪個(gè)，更加靈活。
不同的業(yè)務(wù)模塊可能對異常處理的方式不同，通過該機(jī)制就能做到。
設(shè)想一個(gè)一開始并未使用全局異常處理的系統(tǒng)，如果直接引入全局范圍內(nèi)生效的全局異常處理，勢必可能會改變已有Controller的行為，有侵入性。

也就是說，如果不控制生效范圍，即默認(rèn)對所有Controller生效。如果控制生效范圍，則默認(rèn)對所有Controller不生效，降低侵入性。

如剛才示例中的例子，只針對實(shí)現(xiàn)了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. 總結(jié)

以上幾種方式是Spring專門為異常處理設(shè)計(jì)的機(jī)制。

就我個(gè)人而言，由于ControllerAdvice具有更細(xì)粒度的控制能力，所以我更偏愛于在系統(tǒng)中使用ControllerAdvice進(jìn)行統(tǒng)一異常處理。

除了用異常來傳遞系統(tǒng)中的意外錯(cuò)誤，也會用它來傳遞處于接口行為一部分的業(yè)務(wù)錯(cuò)誤。

這也是異常的優(yōu)點(diǎn)之一，如果接口的實(shí)現(xiàn)比較復(fù)雜，分多層函數(shù)實(shí)現(xiàn)，如果直接傳遞錯(cuò)誤碼，那么到Controller的路徑上的每一層函數(shù)都需要檢查錯(cuò)誤碼，退回到了C語言那種可怕的“寫一行語句檢查一下錯(cuò)誤碼”的模式。

當(dāng)然，理論上，任何能夠給Controller加切面的機(jī)制都能變相的進(jìn)行統(tǒng)一異常處理。比如：