異常處理和日誌輸出使用小結

一、能經過預檢查的異常直接處理，不用catch來處理，沒法經過預檢查的異常纔去使用catch處理；

二、不要對大段代碼進行try catch，只須要在非穩定代碼地方進行try catch處理；

三、異常的捕獲是爲了處理他而不是拋棄它，若是不想處理能夠傳給外層的調用者，可是應用的最外層調用者必須處理它。一般在SpringMVC應用中，controller就已是最外層的調用者了，異常最遲在這裏就必須處理掉而不能將異常拋給前端，返回給前端的必須是一個處理以後的比較友好的提示信息，一般異常是在controller層或者Service層就處理掉；

四、捕獲到異常時，一般作法是先將異常的詳細信息輸出到日誌，而後再給前端返回一個比較友好的提示信息，這樣在前端獲取到異常結果時能夠經過日誌系統快速定位到問題所在，可是一般狀況下日誌會比較多，日誌中定位問題比較困難，有如下兩個建議：
　　1）、日誌記錄詳細儘量詳細，好比說包含出現異常所在的類名、方法名、出錯時間、入參信息、業務異常代碼、異常詳細信息、異常惟一編碼等，若是有異常堆棧建議也一塊兒輸出；
　　2）、在輸出日誌時生成一個異常惟一編碼輸出到日誌中，同時在返回給調用者的信息中帶上這個編碼，這樣在前端捕獲到異常結果時能根據這個異常惟一編碼快速定位到日誌對應地方；]

五、一般要捕獲的異常的地方有：方法入口處進行參數爲空和參數合法性檢查，對框架或者JDK等底層代碼拋出的異常（好比iBatis拋出的數據庫操做異常、Spring框架拋出的異常、RPC調用拋出的異常、網絡操做拋出的異常、除零、空指針、下標越界等JDK拋出的異常等等），業務操做異常（好比查詢數據返回結果爲空、數據業務合法性檢查等等）；其中業務操做異常建議根據業務狀況作一個彙編，將每種異常分配一個統一的編碼和描述信息定義爲一個枚舉值，這樣方便業務異常的排查；

六、必定不要忘記對資源對象、流對象在try finally中關閉，而且還要作異常處理；JDK7及以上的建議使用try-with-resources的方式處理，代碼看起來會簡潔不少；

 

七、不能在finally中使用return，由於這會致使try中的return失效；

八、調用其餘方法必須進行空指針判斷（注意基本數據類型和基本數據類型對象，好比int和Integer，Integer有可能爲NULL，而int不可能爲NULL，還有級聯調用也容易產生空指針異常，好比：obj.getA().getB().getC()）；

九、對於trace/debug/info級別的日誌輸出，必須使用條件輸出或者佔位符的方式，避免執行字符串拼接而浪費系統資源，可是日誌最終卻沒有打印；
　　好比：
　　錯誤：logger.debug("process trade with id:" + id + "and symbol:" + symbol);
　　正確：
　　　　條件輸出：
　　　　　　if (logger.isDebugEnabled()) {
　　　　　　　　logger.debug("process trade with id:" + id + "and symbol:" + symbol);
　　　　　　}
　　　　佔位符：
　　　　　　logger.debug("process trade with id: {} and symbol: {}", id, symbol);

十、謹慎的注意每條日誌輸出的級別設置：debug級別的日誌用於協助調試用的，通常只輸出到開發環境和測試環境嗎，info級別的日誌必須有選擇的輸出，其做用是用於協助查看系統運行情況；debug和info級別的日誌嚴禁在生產環境輸出；warn級別的日誌用於非系統和業務錯誤，可是會影響系統輸出結果的信息，好比記錄用戶輸入參數錯誤的狀況可使用warn級別日誌，避免用戶投訴時有據可依；error級別只記錄系統邏輯錯誤、異常等重要的錯誤信息，如非必要，請不要使用這個級別；