一次和前端的相互甩鍋的問題記錄

bergwhite 發(fā)布于2019-08-16 17:59 / 3301人閱讀

摘要：如果沒有要求，前端直接展示后端返回的錯誤消息。為了統(tǒng)一異常處理，一般公司的做法都是統(tǒng)一返回一套數(shù)據(jù)格式，碼，代表正常，其他表示異常。那么前端處理異常的邏輯這次的問題就是走到的分支了。和前端討論了下，確定了解法。

背景

我們在APP上有個功能，需要獲取用戶當(dāng)前定位，然后當(dāng)用戶關(guān)閉了GPS后，沒有獲取到用戶定位，會觸發(fā)一個bug,彈窗內(nèi)容如下。

問題分析

這個問題的直接原因就是移動端的值取不到，導(dǎo)致沒有給變量賦值，就將"undefined"傳給了后端，后端的這個值定義的Integer，類型轉(zhuǎn)換失敗，報錯。

深層原因是異常處理機(jī)制有問題，于是后端和前端開始撕逼了

前端觀點(diǎn): 后端代碼太不健壯了，就算前端傳錯了，也應(yīng)該具備容錯性;此外APP是有版本的，就算hotfix，用戶也不一定升級，上一版本用戶還是會有問題，所以這種問題盡量是后端來修復(fù)。

后端觀點(diǎn)：前端沒有異常兜底機(jī)制，用戶不應(yīng)該看到任何這種程序異常。對于有定制需求的異常，報特定異常，沒有應(yīng)該顯示通用異常，比如彈窗"服務(wù)不可用"。另外這種屬于http請求層面的約束，前端不遵從約束，還來怪我。我后端框架層面就給你攔截了，沒到業(yè)務(wù)代碼。

雙方說的都好有道理，誰也說服不了誰。但是關(guān)于目標(biāo)大家達(dá)成一致：堅(jiān)決不能讓用戶看到這種類型的彈窗異常。

既然說服不了對方，就只能從更深入的分析問題，看看更合理的解法

通用異常的處理方式

http通常錯誤有

4開頭：客戶端參數(shù)有問題，需要后端提供debug信息。理論上應(yīng)該只是聯(lián)調(diào)的時候會出現(xiàn)，但是實(shí)際上不一定（這不就打臉了嗎）

5開頭：服務(wù)器端有錯誤，客戶端有統(tǒng)一提供的異常處理

2開頭：業(yè)務(wù)異常，如果有UI要求，后端返回一個code碼，前端根據(jù)code碼，展示UI。如果沒有UI要求，前端直接展示后端返回的錯誤消息。

為了統(tǒng)一異常處理，一般公司的做法都是API統(tǒng)一返回一套數(shù)據(jù)格式，

{
    "error_code": "xx", // code碼，1代表正常，其他表示異常。
    "error_msg": "xx" // msg，錯誤提示消息
    "data": "xx" // 正常數(shù)據(jù)
}

我們也是，并且將4開頭的都統(tǒng)一處理成這套統(tǒng)一的數(shù)據(jù)格式。

那么前端處理異常的邏輯

這次的問題就是走到2的分支了。

前后端都沒做錯，問題是后端對于異常模型的抽象有問題，客戶端參數(shù)有問題，需要后端提供debug信息，而不是給用戶展示的錯誤信息。

其實(shí)服務(wù)端對于異常就分三種

客戶端參數(shù)有問題的異常（前端需要debug信息和錯誤msg信息）

需要用戶知道的業(yè)務(wù)異常，前端需要根據(jù)code展示的（前端需要code碼）

通用的服務(wù)端異常，包裝成消息給前端。（前端需要錯誤msg信息）

解法

分析清楚了問題后，就有了解法。

解法1：錯誤消息和debug消息分離，返回的API統(tǒng)一格式中增加一種字段。debug_msg 給開發(fā)看的,error_msg 還是給用戶看的

解法2：定義幾個枚舉code。作為開發(fā)的約定

code	error_msg	參數(shù)錯誤含義
010000	系統(tǒng)錯誤[010000]	請求方法不支持
010001	系統(tǒng)錯誤[010001]	缺少路徑參數(shù)
010002	系統(tǒng)錯誤[010002]	缺少必須的請求參數(shù)
010003	系統(tǒng)錯誤[010003]	類型不匹配
010004	系統(tǒng)錯誤[010004]	請求體異常
010005	系統(tǒng)錯誤[010005]	// 參數(shù)校驗(yàn)異常(body 或 param)
010006	系統(tǒng)錯誤[010006]	參數(shù)綁定異常(表單)

解法1定義比較清晰，但是為了這種corner case增加了一個字段的開銷，網(wǎng)絡(luò)傳輸代價高了。另外還需要前端配合更改，改動成本比較大。

解法2兼容了現(xiàn)在的實(shí)現(xiàn)，前端不用更改，但是對于客戶端參數(shù)有問題這種錯誤提醒不是很友好，不能向前端顯示具體的參數(shù)錯誤了。只能打日志。

和前端討論了下，確定了解法2。

總結(jié)

所以這個問題，最后的解法

前端獲取不到定位時，將undefined這個變量賦值

后端針對移動端這個服務(wù)，改動了異常處理機(jī)制

@RestControllerAdvice
public class ApiStandardException {
    private static final String ERROR_MSG = "系統(tǒng)錯誤";
 
    @ExceptionHandler(value = Exception.class)
    public ResponseEntity handle(final Exception ex, final WebRequest request)
            throws Exception {

        try {
            if (ex instanceof HttpRequestMethodNotSupportedException) {
                // 請求方法不支持
                LOG.warn("Request method is not supported");
                throw new BusinessException(WebRequestErrorEnum.METHOD_ERR.getCode(), ERROR_MSG);
            } else if (ex instanceof MissingPathVariableException) {
                LOG.warn("MISSING_PATHVAR" + ex.getMessage());
                // 缺少路徑參數(shù)
                throw new BusinessException(WebRequestErrorEnum.MISSING_PARAM.getCode(), ERROR_MSG);
            } else if (ex instanceof MissingServletRequestParameterException) {
                // 缺少必須的請求參數(shù)
            }
            // 省略其他異常處理