深入聊一聊springboot項目全局異常處理那些事兒

更新時間：2022年01月21日 09:07:18 作者：linyb極客之路

最近在做項目時需要對異常進(jìn)行全局統(tǒng)一處理,所以下面這篇文章主要給大家介紹了關(guān)于springboot項目全局異常處理那些事兒,文中通過實例代碼介紹的非常詳細(xì),需要的朋友可以參考下

前言
問題一：全局異常抽離出來后，業(yè)務(wù)錯誤碼如何定義？
問題二：全局異常因引入了和業(yè)務(wù)相同的依賴jar，但jar存在版本差異
問題三：引入maven optional標(biāo)簽后，因業(yè)務(wù)沒引入全局異常需要的jar，導(dǎo)致項目啟動報錯
總結(jié)
demo鏈接

前言

之前我們業(yè)務(wù)團(tuán)隊在處理全局異常時，在每個業(yè)務(wù)微服務(wù)中都加入了@RestControllerAdvice+@ExceptionHandler來進(jìn)行全局異常捕獲。某次領(lǐng)導(dǎo)在走查代碼的時候，就提出了一個問題，為什么要每個微服務(wù)項目都要自己在寫一套全局異常代碼，為什么不把全局異常塊抽成一個公共的jar，然后每個微服務(wù)以jar的形式引入。后面業(yè)務(wù)團(tuán)隊就根據(jù)領(lǐng)導(dǎo)的要求，把全局異常塊單獨抽離出來封裝成jar。今天聊的話題就是關(guān)于把全局異常抽離出來，發(fā)生的一些問題

問題一：全局異常抽離出來后，業(yè)務(wù)錯誤碼如何定義？

之前團(tuán)隊的業(yè)務(wù)錯誤碼定義是：業(yè)務(wù)服務(wù)前綴 + 業(yè)務(wù)模塊 + 錯誤碼，如果是識別不了的異常，則使用業(yè)務(wù)前綴 + 固定模塊碼 + 固定錯誤碼。

之前的全局異常偽代碼如下

@RestControllerAdvice
@Slf4j
public class GlobalExceptionBaseHandler {

   
    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public AjaxResult handleException(Exception e) {
        String servicePrifix = "U";
        String moudleCode = "001";
        String code = "0001";
        String errorCode = servicePrifix + moudleCode + code;
        String msg = e.getMessage();
        if(StringUtils.isEmpty(msg)){
            msg = "服務(wù)端異常";
        }
        log.error(msg, e);
        return AjaxResult.error(msg, errorCode);
    }
    }

現(xiàn)在全局異常抽離出來后，那個業(yè)務(wù)服務(wù)前綴如何識別？之前未抽離時，業(yè)務(wù)服務(wù)前綴各個業(yè)務(wù)服務(wù)直接寫死在代碼里。

當(dāng)時我們臨時的解決方案是通過spring.application.name來解決。因為全局異常代碼塊抽離出來后，最終還是要被服務(wù)引入的。因此獲取業(yè)務(wù)服務(wù)前綴的偽代碼可以通過如下獲取

public enum  ServicePrefixEnum {

    USER_SERVICE("U","用戶中心");

    private final String servicePrefix;

    private final String serviceDesc;

    ServicePrefixEnum(String servicePrefix,String serviceDesc) {
        this.servicePrefix = servicePrefix;
        this.serviceDesc = serviceDesc;
    }

    public String getServicePrefix() {
        return servicePrefix;
    }

    public String getServiceDesc() {
        return serviceDesc;
    }
}

public String getServicePrefix(@Value("${spring.application.name}") String serviceName){
      return ServicePrefixEnum.valueOf(serviceName).getServicePrefix();
    }

但這種方案其實是存在弊端

弊端一： 通過枚舉硬編碼，預(yù)設(shè)了目前了微服務(wù)名稱，一旦項目改變了微服務(wù)名，就找不到服務(wù)前綴了。

弊端二： 如果新上線了業(yè)務(wù)服務(wù)模塊，這個枚舉類還得改動

后面我們在全局異常jar中增加了自定義業(yè)務(wù)碼的配置，業(yè)務(wù)人員僅需在springboot配置文件配置，形如下

lybgeek:
  bizcode:
    prefix: U

此時全局異常改造示例形如下

@RestControllerAdvice
@Slf4j
public class GlobalExceptionBaseHandler {
    
    
    @Autowired
    private ServiceCodeProperties serviceCodeProperties;

   
    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public AjaxResult handleException(Exception e) {
        String servicePrifix = serviceCodeProperties.getPrifix();
        String moudleCode = "001";
        String code = "0001";
        String errorCode = servicePrifix + moudleCode + code;
        String msg = e.getMessage();
        if(StringUtils.isEmpty(msg)){
            msg = "服務(wù)端異常";
        }
        log.error(msg, e);
        return AjaxResult.error(msg, errorCode);
    }
}

問題二：全局異常因引入了和業(yè)務(wù)相同的依賴jar，但jar存在版本差異

如果全局異常直接如下寫，是不存在問題。示例如下

@RestControllerAdvice
@Slf4j
public class GlobalExceptionBaseHandler {


    @Autowired
    private ServiceCodeProperties serviceCodeProperties;

    
    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public AjaxResult handleException(Exception e) {
        String servicePrifix = serviceCodeProperties.getPrifix();
        String moudleCode = "001";
        String code = "0001";
        String errorCode = servicePrifix + moudleCode + code;
        String msg = e.getMessage();
        if(StringUtils.isEmpty(msg)){
            msg = "服務(wù)端異常";
        }
        log.error(msg, e);
        return AjaxResult.error(msg, HttpStatus.INTERNAL_SERVER_ERROR.value());
    }


    @ExceptionHandler(BizException.class)
    public AjaxResult handleException(BizException e)
    {
        return AjaxResult.error(e.getMessage(), e.getErrorCode());
    }

}

即全局異常直接分為業(yè)務(wù)異常和Execption這兩種，這樣劃分的弊端在于沒辦法細(xì)分異常，而且也使項目組定義的模塊碼和業(yè)務(wù)碼沒法細(xì)分。因此我們也列出常用可以預(yù)知的系統(tǒng)異常，示例如下

/**
     *參數(shù)驗證失敗
     * @param e
     * @return
     */
    @ExceptionHandler(ConstraintViolationException.class)
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public AjaxResult handleException(ConstraintViolationException e)
    {
        log.error("參數(shù)驗證失敗", e);
        return AjaxResult.error("參數(shù)驗證失敗", HttpStatus.BAD_REQUEST.value());
    }

   /**
     * 數(shù)據(jù)庫異常
     * @param e
     * @return
     */
    @ExceptionHandler({SQLException.class, MybatisPlusException.class,
            MyBatisSystemException.class, org.apache.ibatis.exceptions.PersistenceException.class,
            BadSqlGrammarException.class
    })
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public AjaxResult dbException(Exception e) {
        String msg = ExceptionUtil.getExceptionMessage(e);
        log.error(msg, e);
        return AjaxResult.error(msg,HttpStatus.BAD_REQUEST.value());
    }

    /**
     * 數(shù)據(jù)庫中已存在該記錄
     * @param e
     * @return
     */
    @ExceptionHandler(DuplicateKeyException.class)
    @ResponseStatus(HttpStatus.CONFLICT)
    public AjaxResult handleException(DuplicateKeyException e)
    {
        log.error("數(shù)據(jù)庫中已存在該記錄", e);
        return AjaxResult.error("數(shù)據(jù)庫中已存在該記錄", HttpStatus.CONFLICT.value());
    }

不過這樣導(dǎo)致了一個問題，就是全局異常和業(yè)務(wù)方使用相同的依賴jar，但存在版本差異時，可能就會存在依賴沖突，導(dǎo)致業(yè)務(wù)項目啟動報錯。因此解決方案就是在pom文件加入optional標(biāo)簽。示例如下

<dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <optional>true</optional>
        </dependency>

這標(biāo)簽的意思這jar坐標(biāo)是可選的，因此如果項目中已經(jīng)有引入該jar的坐標(biāo)，就直接用該jar的坐標(biāo)

問題三：引入maven optional標(biāo)簽后，因業(yè)務(wù)沒引入全局異常需要的jar，導(dǎo)致項目啟動報錯

這個問題的產(chǎn)生：舉個示例，我們的業(yè)務(wù)微服務(wù)項目有聚合層，某些聚合層是不需要依賴存儲介質(zhì)，比如mysql。因此這些聚合層項目pom就不會引入類似mybatis相關(guān)的依賴。但我們的全局異常又需要類似mybatis相關(guān)的依賴，這樣導(dǎo)致如果要引用全局異常模塊，有得額外加入業(yè)務(wù)方不需要的jar。

因此springboot的條件注解就派上用場了，利用@ConditionalOnClass注解。示例如下

@RestControllerAdvice
@Slf4j
@ConditionalOnClass({SQLException.class, MybatisPlusException.class,
        MyBatisSystemException.class, org.apache.ibatis.exceptions.PersistenceException.class,
        BadSqlGrammarException.class, DuplicateKeyException.class})
public class GlobalExceptionDbHandler {

    /**
     * 數(shù)據(jù)庫異常
     * @param e
     * @return
     */
    @ExceptionHandler({SQLException.class, MybatisPlusException.class,
            MyBatisSystemException.class, org.apache.ibatis.exceptions.PersistenceException.class,
            BadSqlGrammarException.class
    })
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public AjaxResult dbException(Exception e) {
        String msg = ExceptionUtil.getExceptionMessage(e);
        log.error(msg, e);
        return AjaxResult.error(msg,HttpStatus.BAD_REQUEST.value());
    }

    /**
     * 數(shù)據(jù)庫中已存在該記錄
     * @param e
     * @return
     */
    @ExceptionHandler(DuplicateKeyException.class)
    @ResponseStatus(HttpStatus.CONFLICT)
    public AjaxResult handleException(DuplicateKeyException e)
    {
        log.error("數(shù)據(jù)庫中已存在該記錄", e);
        return AjaxResult.error("數(shù)據(jù)庫中已存在該記錄", HttpStatus.CONFLICT.value());
    }
}

@ConditionalOnClass這個注解的作用就是如果classpath存在指定的類，則該注解上的類會生效。

同時這邊有個細(xì)節(jié)點，就是全局異?？赡芫偷眉?xì)分，即把原來的大一統(tǒng)的全局異常，按業(yè)務(wù)場景分開，比如存儲介質(zhì)相關(guān)的存儲異常，web相關(guān)異常

總結(jié)

本文主要講當(dāng)將全局異常抽離成jar，可能會發(fā)生的問題。這邊有涉及到一些細(xì)節(jié)點沒講，比如為啥要定義服務(wù)前綴+業(yè)務(wù)模塊碼+錯誤碼，其實主要還是為了好排查問題。

也許有朋友會問，你們都搞了微服務(wù)，難道不上分布式鏈路追蹤？根據(jù)分布式鏈路追蹤可以很方便定位到整個鏈路了。但真的開發(fā)微服務(wù)的時候，如果公司原來就就沒運(yùn)維平臺，有時候為了成本考量，測試、開發(fā)環(huán)境都不會上的分布式鏈路追蹤的，甚至線上項目初期也不會上分布式鏈路追蹤。因此定義好相關(guān)的業(yè)務(wù)碼就變得格外重要

到此這篇關(guān)于springboot項目全局異常處理那些事兒的文章就介紹到這了,更多相關(guān)springboot項目全局異常處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！