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

bergwhite 發布于2019-08-16 17:59 / 3307人閱讀

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

背景

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

問題分析

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

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

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

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

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

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

通用異常的處理方式

http通常錯誤有

4開頭：客戶端參數有問題，需要后端提供debug信息。理論上應該只是聯調的時候會出現，但是實際上不一定（這不就打臉了嗎）

5開頭：服務器端有錯誤，客戶端有統一提供的異常處理

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

為了統一異常處理，一般公司的做法都是API統一返回一套數據格式，

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

我們也是，并且將4開頭的都統一處理成這套統一的數據格式。

那么前端處理異常的邏輯

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

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

其實服務端對于異常就分三種

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

需要用戶知道的業務異常，前端需要根據code展示的（前端需要code碼）

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

解法

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

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

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

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

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

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

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

總結

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

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

后端針對移動端這個服務，改動了異常處理機制

@RestControllerAdvice
public class ApiStandardException {
    private static final String ERROR_MSG = "系統錯誤";
 
    @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());
                // 缺少路徑參數
                throw new BusinessException(WebRequestErrorEnum.MISSING_PARAM.getCode(), ERROR_MSG);
            } else if (ex instanceof MissingServletRequestParameterException) {
                // 缺少必須的請求參數
            }
            // 省略其他異常處理

云服務器 GPU云服務器的相互監視記錄問題博客 asp問題記錄系統 java前端安全問題

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/74867.html

程序員，職場上請遠離這種人！

摘要：隨著微信和的不斷普及，現在微信和留言也已經成為了甩鍋證據的一部分，經常郵件里面大量粘貼微信聊天截圖，職場上的宮心斗不比電視劇里面的差。對有些職場人來講，甩鍋就是一種生存手段。 01.從大學打籃球說起上大學的時候喜歡打籃球，然后我又特別喜歡搶籃板，經常是跳起來的時候沒...

khs1994 2021-09-02 15:21 評論0 收藏0
前端開發流程中一定要注意的5個點！

摘要：作為一個老前端給新人們的一些關于開發流程上的建議拒絕和設計稿沒有封板就要求排期，和產品設計充分溝通。雙方還是要找到平衡點確保產品質量和上線時間點的前提下，前端的開發難度和工作量是合理的。作為一個老前端給新人們的一些關于開發流程上的建議 1. 拒絕PRD和設計稿沒有封板就要求排期，和產品設計充分溝通。前端開發經常會遇到這樣的情況，項目經理莫名奇妙發了個會議邀請，然后一股腦把產品下階段...

王晗 2019-08-23 16:52 評論0 收藏0
CDN的入門了解

摘要：維基百科的基本工作過程最簡單的網絡是由一臺服務器和多臺緩存服務器構成。用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。前言這段時間，在工作中遇到了一個CDN導致的圖片資源加載的錯誤，在排查問題的過程中，發現自己對CDN的了解非常的片面，僅僅停留在它能緩存靜態資源，提升訪問速度的了解中。所以覺得還是非常有必要深入去了解下。什么是CDN? CDN的全稱...

wapeyang 2019-08-26 11:58 評論0 收藏0
CDN的入門了解

摘要：維基百科的基本工作過程最簡單的網絡是由一臺服務器和多臺緩存服務器構成。用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。前言這段時間，在工作中遇到了一個CDN導致的圖片資源加載的錯誤，在排查問題的過程中，發現自己對CDN的了解非常的片面，僅僅停留在它能緩存靜態資源，提升訪問速度的了解中。所以覺得還是非常有必要深入去了解下。什么是CDN? CDN的全稱...

Gilbertat 2019-08-02 10:36 評論0 收藏0
Python源碼漫游指南（一）

摘要：源碼漫游指南一作者秘塔科技算法研究員前幾天發布了第五屆頂級語言交互排行榜，語言繼續穩坐第一把交椅，并且相比去年的排行情況，拉開了與第二名的距離去年第二名的排名得分為。包含字節碼相關的底層抽象。字節碼對象的實現。源文件執行結束后的清理工作。 Python源碼漫游指南（一）作者：秘塔科技算法研究員 Qian Wan 前幾天IEEE Spectrum發布了第五屆頂級語言交互排行榜，Pyth...

dackel 2019-07-30 17:22 評論0 收藏0