資訊專欄INFORMATION COLUMN
摘要：如果沒有要求，前端直接展示后端返回的錯(cuò)誤消息。為了統(tǒng)一異常處理，一般公司的做法都是統(tǒng)一返回一套數(shù)據(jù)格式，碼，代表正常，其他表示異常。那么前端處理異常的邏輯這次的問題就是走到的分支了。和前端討論了下，確定了解法。
背景
我們?cè)贏PP上有個(gè)功能，需要獲取用戶當(dāng)前定位，然后當(dāng)用戶關(guān)閉了GPS后，沒有獲取到用戶定位，會(huì)觸發(fā)一個(gè)bug,彈窗內(nèi)容如下。
問題分析這個(gè)問題的直接原因就是移動(dòng)端的值取不到，導(dǎo)致沒有給變量賦值，就將"undefined"傳給了后端，后端的這個(gè)值定義的Integer，類型轉(zhuǎn)換失敗，報(bào)錯(cuò)。
深層原因是異常處理機(jī)制有問題，于是后端和前端開始撕逼了
前端觀點(diǎn): 后端代碼太不健壯了， 就算前端傳錯(cuò)了，也應(yīng)該具備容錯(cuò)性;此外APP是有版本的，就算hotfix，用戶也不一定升級(jí)，上一版本用戶還是會(huì)有問題，所以這種問題盡量是后端來修復(fù)。
后端觀點(diǎn)：前端沒有異常兜底機(jī)制，用戶不應(yīng)該看到任何這種程序異常。對(duì)于有定制需求的異常，報(bào)特定異常，沒有應(yīng)該顯示通用異常，比如彈窗"服務(wù)不可用"。另外這種屬于http請(qǐng)求層面的約束，前端不遵從約束，還來怪我。我后端框架層面就給你攔截了，沒到業(yè)務(wù)代碼。
雙方說的都好有道理，誰也說服不了誰。但是關(guān)于目標(biāo)大家達(dá)成一致：堅(jiān)決不能讓用戶看到這種類型的彈窗異常。
既然說服不了對(duì)方，就只能從更深入的分析問題，看看更合理的解法
通用異常的處理方式http通常錯(cuò)誤有
4開頭：客戶端參數(shù)有問題，需要后端提供debug信息。理論上應(yīng)該只是聯(lián)調(diào)的時(shí)候會(huì)出現(xiàn)，但是實(shí)際上不一定（這不就打臉了嗎）
5開頭：服務(wù)器端有錯(cuò)誤，客戶端有統(tǒng)一提供的異常處理
2開頭：業(yè)務(wù)異常，如果有UI要求，后端返回一個(gè)code碼，前端根據(jù)code碼，展示UI。如果沒有UI要求，前端直接展示后端返回的錯(cuò)誤消息。
為了統(tǒng)一異常處理，一般公司的做法都是API統(tǒng)一返回一套數(shù)據(jù)格式，
{
"error_code": "xx", // code碼，1代表正常，其他表示異常。
"error_msg": "xx" // msg，錯(cuò)誤提示消息
"data": "xx" // 正常數(shù)據(jù)
}
我們也是，并且將4開頭的都統(tǒng)一處理成這套統(tǒng)一的數(shù)據(jù)格式。
那么前端處理異常的邏輯
這次的問題就是走到2的分支了。
前后端都沒做錯(cuò)，問題是后端對(duì)于異常模型的抽象有問題，客戶端參數(shù)有問題，需要后端提供debug信息，而不是給用戶展示的錯(cuò)誤信息。
其實(shí)服務(wù)端對(duì)于異常就分三種
客戶端參數(shù)有問題的異常（前端需要debug信息和錯(cuò)誤msg信息）
需要用戶知道的業(yè)務(wù)異常，前端需要根據(jù)code展示的（前端需要code碼）
通用的服務(wù)端異常，包裝成消息給前端。（前端需要錯(cuò)誤msg信息）
解法分析清楚了問題后，就有了解法。
解法1：錯(cuò)誤消息和debug消息分離，返回的API統(tǒng)一格式中增加一種字段。debug_msg 給開發(fā)看的,error_msg 還是給用戶看的
解法2：定義幾個(gè)枚舉code。作為開發(fā)的約定
| code | error_msg | 參數(shù)錯(cuò)誤含義 | |
|---|---|---|---|
| 010000 | 系統(tǒng)錯(cuò)誤[010000] | 請(qǐng)求方法不支持 | |
| 010001 | 系統(tǒng)錯(cuò)誤[010001] | 缺少路徑參數(shù) | |
| 010002 | 系統(tǒng)錯(cuò)誤[010002] | 缺少必須的請(qǐng)求參數(shù) | |
| 010003 | 系統(tǒng)錯(cuò)誤[010003] | 類型不匹配 | |
| 010004 | 系統(tǒng)錯(cuò)誤[010004] | 請(qǐng)求體異常 | |
| 010005 | 系統(tǒng)錯(cuò)誤[010005] | // 參數(shù)校驗(yàn)異常(body 或 param) | |
| 010006 | 系統(tǒng)錯(cuò)誤[010006] | 參數(shù)綁定異常(表單) |
解法1定義比較清晰，但是為了這種corner case增加了一個(gè)字段的開銷，網(wǎng)絡(luò)傳輸代價(jià)高了。另外還需要前端配合更改，改動(dòng)成本比較大。
解法2兼容了現(xiàn)在的實(shí)現(xiàn)，前端不用更改，但是對(duì)于客戶端參數(shù)有問題這種錯(cuò)誤提醒不是很友好，不能向前端顯示具體的參數(shù)錯(cuò)誤了。只能打日志。
和前端討論了下，確定了解法2。
總結(jié)所以這個(gè)問題，最后的解法
前端獲取不到定位時(shí)，將undefined這個(gè)變量賦值
后端針對(duì)移動(dòng)端這個(gè)服務(wù)，改動(dòng)了異常處理機(jī)制
@RestControllerAdvice
public class ApiStandardException {
private static final String ERROR_MSG = "系統(tǒng)錯(cuò)誤";
@ExceptionHandler(value = Exception.class)
public ResponseEntity handle(final Exception ex, final WebRequest request)
throws Exception {
try {
if (ex instanceof HttpRequestMethodNotSupportedException) {
// 請(qǐng)求方法不支持
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) {
// 缺少必須的請(qǐng)求參數(shù)
}
// 省略其他異常處理
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/74867.html
摘要：隨著微信和的不斷普及，現(xiàn)在微信和留言也已經(jīng)成為了甩鍋?zhàn)C據(jù)的一部分，經(jīng)常郵件里面大量粘貼微信聊天截圖，職場(chǎng)上的宮心斗不比電視劇里面的差。 對(duì)有些職場(chǎng)人來講，甩鍋就是一種生存手段。 01.從大學(xué)打籃球說起 上大學(xué)的時(shí)候喜歡打籃球，然后我又特別喜歡搶籃板，經(jīng)常是跳起來的時(shí)候沒...
摘要：作為一個(gè)老前端給新人們的一些關(guān)于開發(fā)流程上的建議拒絕和設(shè)計(jì)稿沒有封板就要求排期，和產(chǎn)品設(shè)計(jì)充分溝通。雙方還是要找到平衡點(diǎn)確保產(chǎn)品質(zhì)量和上線時(shí)間點(diǎn)的前提下，前端的開發(fā)難度和工作量是合理的。 作為一個(gè)老前端給新人們的一些關(guān)于開發(fā)流程上的建議 1. 拒絕PRD和設(shè)計(jì)稿沒有封板就要求排期，和產(chǎn)品設(shè)計(jì)充分溝通。 前端開發(fā)經(jīng)常會(huì)遇到這樣的情況，項(xiàng)目經(jīng)理莫名奇妙發(fā)了個(gè)會(huì)議邀請(qǐng)，然后一股腦把產(chǎn)品下階段...
摘要：維基百科的基本工作過程最簡(jiǎn)單的網(wǎng)絡(luò)是由一臺(tái)服務(wù)器和多臺(tái)緩存服務(wù)器構(gòu)成。用戶向緩存服務(wù)器發(fā)起請(qǐng)求，緩存服務(wù)器響應(yīng)用戶請(qǐng)求，將用戶所需內(nèi)容傳送到用戶終端。 前言 這段時(shí)間，在工作中遇到了一個(gè)CDN導(dǎo)致的圖片資源加載的錯(cuò)誤，在排查問題的過程中，發(fā)現(xiàn)自己對(duì)CDN的了解非常的片面，僅僅停留在它能緩存靜態(tài)資源，提升訪問速度的了解中。所以覺得還是非常有必要深入去了解下。 什么是CDN? CDN的全稱...
摘要：維基百科的基本工作過程最簡(jiǎn)單的網(wǎng)絡(luò)是由一臺(tái)服務(wù)器和多臺(tái)緩存服務(wù)器構(gòu)成。用戶向緩存服務(wù)器發(fā)起請(qǐng)求，緩存服務(wù)器響應(yīng)用戶請(qǐng)求，將用戶所需內(nèi)容傳送到用戶終端。 前言 這段時(shí)間，在工作中遇到了一個(gè)CDN導(dǎo)致的圖片資源加載的錯(cuò)誤，在排查問題的過程中，發(fā)現(xiàn)自己對(duì)CDN的了解非常的片面，僅僅停留在它能緩存靜態(tài)資源，提升訪問速度的了解中。所以覺得還是非常有必要深入去了解下。 什么是CDN? CDN的全稱...
摘要：源碼漫游指南一作者秘塔科技算法研究員前幾天發(fā)布了第五屆頂級(jí)語言交互排行榜，語言繼續(xù)穩(wěn)坐第一把交椅，并且相比去年的排行情況，拉開了與第二名的距離去年第二名的排名得分為。包含字節(jié)碼相關(guān)的底層抽象。字節(jié)碼對(duì)象的實(shí)現(xiàn)。源文件執(zhí)行結(jié)束后的清理工作。 Python源碼漫游指南（一） 作者：秘塔科技算法研究員 Qian Wan 前幾天IEEE Spectrum發(fā)布了第五屆頂級(jí)語言交互排行榜，Pyth...
閱讀 3656·2023-04-26 02:10
閱讀 1479·2021-11-22 15:25
閱讀 1741·2021-09-22 10:02
閱讀 985·2021-09-06 15:02
閱讀 3542·2019-08-30 15:55
閱讀 668·2019-08-30 13:58
閱讀 2841·2019-08-30 12:53
閱讀 3132·2019-08-29 12:38
