## 一、異常處理的亂象例舉 ### 亂象一：捕獲異常后只輸出到控制臺 前端js-ajax代碼 ~~~ $.ajax({ type: "GET", url: "/user/add", dataType: "json", success: function(data){ alert("添加成功"); } }); ~~~ 后端業務代碼 ~~~ try { // do something } catch (XyyyyException e) { e.printStackTrace(); } ~~~ 問題： 1. 后端直接將異常捕獲，而且只做了日志打印。用戶體驗非常差，一旦后臺出錯，用戶沒有任何感知，頁面無狀態，。 2. 如果沒有人去經常關注日志，不會有人發現系統出現異常 ### 亂象二：混亂的返回方式 前端代碼 ~~~ $.ajax({ type: "GET", url: "/goods/add", dataType: "json", success: function(data) { if (data.flag) { alert("添加成功"); } else { alert(data.message); } }, error: function(data){ alert("添加失敗"); } }); ~~~ 后端代碼 ~~~ @RequestMapping("/goods/add") @ResponseBody public Map add(Goods goods) { Map map = new HashMap(); try { // do something map.put(flag, true); } catch (Exception e) { e.printStackTrace(); map.put("flag", false); map.put("message", e.getMessage()); } reutrn map; } ~~~ 問題： 1. 每個人返回的數據有每個人自己的規范，你叫flag他叫isOK，你的成功code是0，他的成功code是0000。這樣導致后端書寫了大量的異常返回邏輯代碼，前端也隨之每一個請求一套異常處理邏輯。很多重復代碼。 2. 如果是前端后端一個人開發還勉強能用，如果前后端分離，就是系統災難。 參考: [https://juejin.im/post/5c3ea92a5188251e101598aa](https://juejin.im/post/5c3ea92a5188251e101598aa) ## 二、該如何設計異常處理  ### 面向相關方友好 1. 后端開發人員職責單一，只需要將異常捕獲并轉換為自定義異常一直對外拋出。不需要去想頁面跳轉404，以及異常響應的數據結構的設計。 2. 面向前端人員友好，后端返回給前端的數據應該有統一的數據結構，統一的規范。不能一個人一個響應的數據結構。而在此過程中不需要后端開發人員做更多的工作，交給全局異常處理器去處理“異常”到“響應數據結構”的轉換。 3. 面向用戶友好，用戶能夠清楚的知道異常產生的原因。這就要求自定義異常，全局統一處理，ajax接口請求響應統一的異常數據結構，頁面模板請求統一跳轉到404頁面。 4. 面向運維友好，將異常信息合理規范的持久化，以便查詢。 **為什么要將系統運行時異常捕獲，轉換為自定義異常拋出？** 答：因為用戶不認識ConnectionTimeOutException類似這種異常是什么東西，但是轉換為自定義異常就要求程序員對運行時異常進行一個翻譯，比如：自定義異常里面應該有message字段，后端程序員應該明確的在message字段里面用面向用戶的友好語言，說明發生了什么。 ## 三、開發規范 1. Controller、Service、DAO層攔截異常轉換為自定義異常，不允許將異常私自截留。必須對外拋出。 2. 統一數據響應代碼，使用httpstatusode，不要自定義。自定義不方便記憶。200請求成功，400用戶輸入錯誤導致的異常，500系統內部異常，999未知異常。 3. 自定義異常里面有message屬性，一定用友好的語言描述異常，并賦值給message. 4. 不允許對父類Excetion統一catch，要分小類catch，這樣能夠清楚地將異常轉換為自定義異常傳遞給前端。