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

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

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

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

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

http通常錯誤有

為了統一異常處理，一般公司的做法都是api統一返回一套資料格式，

那麼前端處理異常的邏輯

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

前後端都沒做錯，問題是後端對於異常模型的抽象有問題，客戶端引數有問題，需要後端提供debug資訊，而不是給使用者展示的錯誤資訊。

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

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

解法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。

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

@restcontrolleradvice

public class apistandardexception else if (ex instanceof missingpathvariableexception) else if (ex instanceof missingservletrequestparameterexception) 
// 省略其他異常處理

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

這個問題的直接原因就是移動端的值取不到，導致沒有給變數賦值，就將 undefined 傳給了後端，後端的這個值定義的integer，型別轉換失敗，報錯。深層原因是異常處理機制有問題，於是後端和前端開始撕逼了 後端觀點 前端沒有異常兜底機制，使用者不應該看到任何這種程式異常。對於有定製需求的異常，報特...

一次奇葩Hama問題記錄

對hama進行改進，引用了乙個類a a繼承了執行緒類 當該類實現如下時，graphjobrunner 中 override public final void setup bsppeerpeer throws ioexception,syncexception,interruptedexceptio...

一次線上oom問題記錄

某天早上發現服務無法正常訪問，於是展開問題排查。1。首先檢視日誌，發現有oom日誌存在。這時候看到oom，犯了想當然的錯誤，認為是記憶體不足，堆記憶體空間已經用完。於是檢視 發現某個模組中有如下 誰寫的，站出來，我保證不打你。當時盲目的認為就是使用這個執行緒池的問題 關於此執行緒池的弊端不再贅述 於...