對於一個大的專案，最怕兩件事情：

                1. 系統出現問題我們不知道，等到問題慢慢變大，使用者開始投訴後才知道“哦，我們系統出現問題了呀！”。 多麼可怕！！！

                2. 系統出了問題，但是就是找不出來哪裡出現了問題。

        對於第一個問題，如果出現，後果非常的嚴重。 因此，為了儘量避免這樣的問題，我們需要在異常處理方面盡最大的力量做到更好！

        下面，我先將一段在專案中用到的一段程式碼貼出來：

       我們很多人看到這段程式碼，會認為這段程式碼沒有什麼問題（正常執行情況下，這段程式碼也不會出現問題）。 但是，如果問題真的在這段程式碼中出現，開發人員很難知道出現了問題。如果是這種情況，那麼問題就大了，就等著使用者來投訴吧！！

    主要有以下的原因：

         1. 丟掉了異常。 異常資訊就算列印到了堆疊，也不會有人看到！除非問題出現，有使用者投訴時，你才發現出現了問題，開始去查詢日誌！所以，好像看起來很嚴謹的程式碼，其實作用並不大。

         2. 異常處理再加上框2中的空判斷。完美的避開了所有的正確答案。本來需要更新文件，結果什麼錯誤也沒有報，什麼也沒有做。 

   所以————對於開發人員： 絕大部分場景，不允許捕獲異常，不要亂加空判斷！只有明顯不需要關心的異常，如關閉資源的時候的IO異常，可以捕獲，然後什麼都不幹。其他的時候，不允許捕獲異常，都丟擲去，到controller層由AOP去處理。 對於空判斷大部分是不需要的，你如果寫了空判斷，必須要測試為空和不為空二種場景，要麼就不要寫空判斷。

新手最容易犯的錯誤：  到處捕獲異常，到處加空判斷，自以為寫出了“健壯”的程式碼，實際上完全相反。

      比如，某一天你在一個團隊中負責一部分功能程式碼。最後提交程式碼時發現一般程式碼是 try-catch 和空判斷，給人的感覺就是 “ 垃圾 ”。    另一方面，這樣做會掩蓋很多的錯誤。

        所以，上面的程式碼可以這樣修改（異常向上拋給controller層的AOP處理）

        對於異常的定義我在這裡就不介紹了（本博文主要是講一下規範）。

總結：

•    異常由專門的開發人員負責開發，在開發之前實現定義好異常類
•        不允許開發人員捕獲異常
•         後臺異常（如佇列等）異常一定要有異常通知機制，要第一時間知道異常
•         少加空判斷，加了空判斷就要為測試為空和非空的場景。