在具體的SSM項(xiàng)目開(kāi)發(fā)中，由于Controller層為處于請(qǐng)求處理的最頂層，再往上就是框架代碼的。因此，肯定需要在Controller捕獲所有異常，并且做適當(dāng)處理，返回給前端一個(gè)友好的錯(cuò)誤碼。

不過(guò)，Controller一多，我們發(fā)現(xiàn)每個(gè)Controller里都有大量重復(fù)的、冗余的異常處理代碼，很是啰嗦。能否將這些重復(fù)的部分抽取出來(lái)，這樣保證Controller層更專(zhuān)注于業(yè)務(wù)邏輯的處理，同時(shí)能夠使得異常的處理有一個(gè)統(tǒng)一的控制中心點(diǎn)。

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

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

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

在 resolveException 中實(shí)現(xiàn)異常處理邏輯。從參數(shù)上，可以看到，不僅能夠拿到發(fā)生異常的函數(shù)和異常對(duì)象，還能夠拿到 HttpServletResponse對(duì)象，從而控制本次請(qǐng)求返回給前端的行為。

此外，函數(shù)還可以返回一個(gè) ModelAndView 對(duì)象，表示渲染一個(gè)視圖，比方說(shuō)錯(cuò)誤頁(yè)面。不過(guò)，在前后端分離為主流架構(gòu)的今天，這個(gè)很少用了。如果函數(shù)返回的視圖為空，則表示不需要視圖。

1.2. 使用示例

來(lái)看一個(gè)例子：

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

邏輯很顯然，在發(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();
    }
}

1. 所有 Controller 方法（即被 RequestMapping 注解的方法）拋出的異常，會(huì)被該異常處理方法處理。
2. 使用上，在 Controller 內(nèi)部，用?@ExceptionHandler?注解的方法，就會(huì)作為該Controller內(nèi)部的異常處理方法。
3. 并且，它的參數(shù)中可以注入如 WebRequest、NativeWebRequest 等，用來(lái)拿到請(qǐng)求相關(guān)的數(shù)據(jù)。
4. 它可以返回 String 代表一個(gè) view 名稱(chēng)，也可以返回一個(gè)對(duì)象并且用?@ResponseBody?修飾，由框架的其它機(jī)制幫你序列化。

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

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

雖然說(shuō)全局異常處理HandlerExceptionResolver通過(guò)條件判斷也能做到，但是使用這種注解方式明顯更具有可讀性。

1.3.2. 一個(gè)問(wèn)題

剛才說(shuō)到異常處理函數(shù)可以用?@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();
}

不知道是我的使用姿勢(shì)不對(duì)，還是什么情況？各種 Google 后無(wú)果。

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

1.4. ControllerAdvice

1.4.1. 使用示例

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

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

1.4.2. 控制生效的Controller范圍

注意到，我是這樣編寫(xiě)注解的：

@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})

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

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

1. 一個(gè)系統(tǒng)里就能夠存在不同的異常處理器，Controller 也可以有選擇的決定使用哪個(gè)，更加靈活。
2. 不同的業(yè)務(wù)模塊可能對(duì)異常處理的方式不同，通過(guò)該機(jī)制就能做到。
3. 設(shè)想一個(gè)一開(kāi)始并未使用全局異常處理的系統(tǒng)，如果直接引入全局范圍內(nèi)生效的全局異常處理，勢(shì)必可能會(huì)改變已有 Controller 的行為，有侵入性。
   也就是說(shuō)，如果不控制生效范圍，即默認(rèn)對(duì)所有 Controller 生效。如果控制生效范圍，則默認(rèn)對(duì)所有 Controller 不生效，降低侵入性。

如剛才示例中的例子，只針對(duì)實(shí)現(xiàn)了 GlobalExceptionHandlerMixin 接口的類(lèi)有效：

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

ControllerAdvice 支持的限定范圍

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

標(biāo)簽： Google 代碼

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。