目錄
一 異常處理
1. 【強制】Java 類庫中定義的可以通過預檢查方式規避的 RuntimeException 異常不應該通過 catch 的方式來處理，比如：NullPointerException，IndexOutOfBoundsException 等等。
說明：無法通過預檢查的異常除外，比如，在解析字符串形式的數字時，可能存在數字格式錯誤，不得不通過 catch NumberFormatException 來實現。
正例：if (obj != null) {...}
反例：try { obj.method(); } catch (NullPointerException e) {…}
2. 【強制】異常不要用來做流程控制，條件控制。
說明：異常設計的初衷是解決程序運行中的各種意外情況，且異常的處理效率比條件判斷方式要低很多。
3. 【強制】catch 時請分清穩定代碼和非穩定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分異常類型，再做對應的異常處理。
說明：對大段代碼進行 try-catch，使程序無法根據不同的異常做出正確的應激反應，也不利於定位問題，這是一種不負責任的表現。
正例：用戶註冊的場景中，如果用戶輸入非法字符，或用戶名稱已存在，或用戶輸入密碼過於簡單，在程序上作出分門別類的判斷，並提示給用戶。
4. 【強制】捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請將該異常拋給它的調用者。最外層的業務使用者，必須處理異常，將其轉化爲用戶可以理解的內容。
5. 【強制】有 try 塊放到了事務代碼中，catch 異常後，如果需要回滾事務，一定要注意手動回滾事務。
6. 【強制】finally 塊必須對資源對象、流對象進行關閉，有異常也要做 try-catch。
說明：如果 JDK7 及以上，可以使用 try-with-resources 方式。
7. 【強制】不要在 finally 塊中使用 return。
說明：try 塊中的 return 語句執行成功後，並不馬上返回，而是繼續執行 finally 塊中的語句，如果此處存在 return 語句，則在此直接返回，無情丟棄掉 try 塊中的返回點。
8. 【強制】捕獲異常與拋異常，必須是完全匹配，或者捕獲異常是拋異常的父類。
說明：如果預期對方拋的是繡球，實際接到的是鉛球，就會產生意外情況。
9. 【強制】在調用 RPC、二方包、或動態生成類的相關方法時，捕捉異常必須使用 Throwable 類來進行攔截。
說明：通過反射機制來調用方法，如果找不到方法，拋出 NoSuchMethodException。什麼情況會拋出 NoSuchMethodError 呢？二方包在類衝突時，仲裁機制可能導致引入非預期的版本使類的方法簽名不匹配，或者在字節碼修改框架（比如：ASM）動態創建或修改類時，修改了相應的方法簽名。這些情況，即使代碼編譯期是正確的，但在代碼運行期時，會拋出 NoSuchMethodError。
10.【推薦】方法的返回值可以爲 null，不強制返回空集合，或者空對象等，必須添加註釋充分說明什麼情況下會返回 null 值。
說明：本手冊明確防止 NPE 是調用者的責任。即使被調用方法返回空集合或者空對象，對調用者來說，也並非高枕無憂，必須考慮到遠程調用失敗、序列化失敗、運行時異常等場景返回 null 的情況。
11.【推薦】防止 NPE，是程序員的基本修養，注意 NPE 產生的場景：
1） 返回類型爲基本數據類型，return 包裝數據類型的對象時，自動拆箱有可能產生 NPE。
反例：public int f() { return Integer 對象}， 如果爲 null，自動解箱拋 NPE。
2） 數據庫的查詢結果可能爲 null。
3） 集合裏的元素即使 isNotEmpty，取出的數據元素也可能爲 null。
4） 遠程調用返回對象時，一律要求進行空指針判斷，防止 NPE。
5） 對於 Session 中獲取的數據，建議進行 NPE 檢查，避免空指針。
6） 級聯調用 obj.getA().getB().getC()；一連串調用，易產生 NPE。
正例：使用 JDK8 的 Optional 類來防止 NPE 問題。
12.【推薦】定義時區分 unchecked / checked 異常，避免直接拋出 new RuntimeException()，更不允許拋出 Exception 或者 Throwable，應使用有業務含義的自定義異常。推薦業界已定義過的自定義異常，如：DAOException / ServiceException 等。
13.【參考】對於公司外的 http/api 開放接口必須使用“錯誤碼”；而應用內部推薦異常拋出；跨應用間 RPC 調用優先考慮使用 Result 方式，封裝 isSuccess()方法、“錯誤碼”、“錯誤簡短信息”。
說明：關於 RPC 方法返回方式使用 Result 方式的理由：
1）使用拋異常返回方式，調用方如果沒有捕獲到就會產生運行時錯誤。
2）如果不加棧信息，只是 new 自定義異常，加入自己的理解的 error message，對於調用端解決問題
的幫助不會太多。如果加了棧信息，在頻繁調用出錯的情況下，數據序列化和傳輸的性能損耗也是問題。
14.【參考】避免出現重複的代碼（Don't Repeat Yourself），即 DRY 原則。
說明：隨意複製和粘貼代碼，必然會導致代碼的重複，在以後需要修改時，需要修改所有的副本，容易遺
漏。必要時抽取共性方法，或者抽象公共類，甚至是組件化。
正例：一個類中有多個 public 方法，都需要進行數行相同的參數校驗操作，這個時候請抽取：
private boolean checkParam(DTO dto) {...}
二 日誌規約
1. 【強制】應用中不可直接使用日誌系統（Log4j、Logback）中的 API，而應依賴使用日誌框架 SLF4J 中的 API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
2. 【強制】所有日誌文件至少保存 15 天，因爲有些異常具備以“周”爲頻次發生的特點。網絡 運行狀態、安全相關信息、系統監測、管理後臺操作、用戶敏感操作需要留存相關的網絡日誌不少於 6 個月。
3. 【強制】應用中的擴展日誌（如打點、臨時監控、訪問日誌等）命名方式： appName_logType_logName.log。logType:日誌類型，如 stats/monitor/access 等；logName:日誌描述。這種命名的好處：通過文件名就可知道日誌文件屬於什麼應用，什麼類型，什麼目的，也有利於歸類查找。
說明：推薦對日誌進行分類，如將錯誤日誌和業務日誌分開存放，便於開發人員查看，也便於通過日誌對系統進行及時監控。
正例：force-web 應用中單獨監控時區轉換異常，如：force_web_timeZoneConvert.log
4. 【強制】在日誌輸出時，字符串變量之間的拼接使用佔位符的方式。
說明：因爲 String 字符串的拼接會使用 StringBuilder 的 append()方式，有一定的性能損耗。使用佔位符僅是替換動作，可以有效提升性能。
正例：logger.debug("Processing trade with id: {} and symbol: {}", id, symbol);
5. 【強制】對於 trace/debug/info 級別的日誌輸出，必須進行日誌級別的開關判斷。
說明：雖然在 debug(參數)的方法體內第一行代碼 isDisabled(Level.DEBUG_INT)爲真時（Slf4j 的常見實現 Log4j 和 Logback），就直接 return，但是參數可能會進行字符串拼接運算。此外，如果debug(getName())這種參數內有 getName()方法調用，無謂浪費方法調用的開銷。
6. 【強制】避免重複打印日誌，浪費磁盤空間，務必在 log4j.xml 中設置 additivity=false。
正例：<logger name="com.taobao.dubbo.config" additivity="false">
7. 【強制】異常信息應該包括兩類信息：案發現場信息和異常堆棧信息。如果不處理，那麼通過關鍵字 throws 往上拋出。
正例：logger.error(各類參數或者對象 toString() + "_" + e.getMessage(), e);
8. 【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌；有選擇地輸出 info 日誌；如果使用 warn 來記錄剛上線時的業務行爲信息，一定要注意日誌輸出量的問題，避免把服務器磁盤撐爆，並記得及時刪除這些觀察日誌。
說明：大量地輸出無效日誌，不利於系統性能提升，也不利於快速定位錯誤點。記錄日誌時請思考：這些日誌真的有人看嗎？看到這條日誌你能做什麼？能不能給問題排查帶來好處？
9. 【推薦】可以使用 warn 日誌級別來記錄用戶輸入參數錯誤的情況，避免用戶投訴時，無所適從。如非必要，請不要在此場景打出 error 級別，避免頻繁報警。
說明：注意日誌輸出的級別，error 級別只記錄系統邏輯出錯、異常或者重要的錯誤信息。
10.【推薦】儘量用英文來描述日誌錯誤信息，如果日誌中的錯誤信息用英文描述不清楚的話使用中文描述即可，否則容易產生歧義。【強制】國際化團隊或海外部署的服務器由於字符集問題，使用全英文來註釋和描述日誌錯誤信息。