《阿里Java開發手冊》 | 異常日誌 - 錯誤碼

【強制】錯誤碼的製定原則：快速溯源、簡單易記、溝通標準化。
說明： 錯誤碼想得過於完美和復雜，就像康熙字典中的生僻字一樣，用詞似乎精準，但是字典不容易隨身攜帶並且簡單易懂。
正例：錯誤碼回答的問題是誰的錯？錯在哪？

• 錯誤碼必須能夠快速知曉錯誤來源，可快速判斷是誰的問題。
• 錯誤碼易於記憶和比對(程式碼中容易 equals)。
• 錯誤碼能夠脫離文件和系統平台達到線下輕量化地自由溝通的目的。

【強制】錯誤碼不體現版本號和錯誤等級訊息。
說明：錯誤碼以不斷追加的方式進行兼容。錯誤等級由日誌和錯誤碼本身的釋義來決定。

【強制】全部正常，但不得不填充錯誤碼時返回五個零:00000。

【強制】錯誤碼為字符串類型，共 5 位，分成兩個部分:錯誤產生來源+四位數字編號。
說明：錯誤產生來源分為 A/B/C ，A 表示錯誤來源於用戶，比如參數錯誤，用戶安裝版本過低，用戶支付超時等問題；B 表示錯誤來源於當前系統，往往是業務邏輯出錯，或程序健壯性差等問題；C 表示錯誤來源於第三方服務，比如 CDN 服務出錯，消息投遞超時等問題；四位數字編號從 0001 到 9999，大類之間的步長間距預留 100，參考文末。

【強制】編號不與公司業務架構，更不與組織架構掛鉤，一切與平台先到先申請的原則進行，審批生效，編號即被永久固定。

【強制】錯誤碼使用者避免隨意定義新的錯誤碼。
說明：盡可能在原有錯誤碼附表中找到語義相同或者相近的錯誤碼在程式碼中使用即可。

【強制】錯誤碼不能直接輸出給用戶作為提示訊息使用。
說明：堆棧(stack_trace)、錯誤訊息(error_message)、錯誤碼(error_code)、提示訊息(user_tip)是一個有效關聯並互相轉義的和諧整體，但是請勿互相越俎代庖。

【推薦】錯誤碼之外的業務獨特訊息由 error_message 來承載，而不是讓錯誤碼本身涵蓋過多具體業務屬性。

【推薦】在獲取第三方服務錯誤碼時，向上拋出允許本系統轉義，由 C 轉為 B，並且在錯誤訊息上帶上原有的第三方錯誤碼。

【參考】錯誤碼分為一級宏觀錯誤碼、二級宏觀錯誤碼、三級宏觀錯誤碼。
說明：在無法更加具體確定的錯誤場景中，可以直接使用一級宏觀錯誤碼，分別是：A0001(用戶端錯誤)、B0001(系統執行出錯)、C0001(調用第三方服務出錯)
正例：調用第三方服務出錯是一級，中間件錯誤是二級，消息服務出錯是三級。

【參考】錯誤碼的後三位編號與 HTTP 狀態碼沒有任何關係。

【參考】錯誤碼盡量有利於不同文化背景的開發者進行交流與程式碼協作。
說明：英文單詞形式的錯誤碼不利於非英語母語國家(如阿拉伯語、希伯來語、俄羅斯語等)之間的開發者互相協作。

【參考】錯誤碼即人性，感性認知+口口相傳，使用純數字來進行錯誤碼編排不利於感性記憶和分類。
說明：數字是一個整體，每位數字的地位和含義是相同的。
反例：一個五位數字 12345，第 1 位是錯誤等級，第 2 位是錯誤來源，345 是編號，人的大腦不會主動地分辨每位數字的不同含義。

錯誤碼列表

心得

看完這篇「錯誤碼」後，首先想說的是「錯誤碼列表」可以拿來做參考，畢竟每家公司需要定義的東西不太一樣；而錯誤碼最簡單要做到的就是簡單易懂清楚表達，可以省去很多查找問題的地方和時間。

結語

文章越看越多，技術越學越多，就會發現自己的不足；技術學到後面都會想要將基礎再重新在打得更加扎實。

以前在開發覺得理所當然的事情，例如：命名規則、命名規範，照著別人怎麼說就怎麼做的想法，並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀，書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明；我相信在閱讀完這一系列後，一定會更加扎實且實在。

如對此書有興趣，建議去購買官方認證的書籍，給予官方支持。

註：如有侵權，通知即刪。

註：以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version