精簡版讀後感 -- 報告所有的異常

[size=large][color=blue]不報告所有異常有什麼壞處[/color][/size]
[size=medium]例如：你在一個方法裏捕獲了一個異常，但是在catch裏沒有做任何事情，也沒有向外擴散這個異常。那麼，當日後程序在生產環境中運行時發生錯誤，拋出這個異常時，方法返回了，運行結果錯誤，最終用戶看不到任何錯誤提示。bug修復人員也無法很快定位錯誤，因爲錯誤的表現形式是多樣的，唯一能做的就是一步步調試找到錯誤的位置。如果碰巧這個bug的環境很難重現的話，對開發人員來說是一場災難。[/size]


[size=large][color=blue]爲什麼要報告所有異常[/color][/size]
[size=medium] 1 大部分異常都是程序出現錯誤，很難恢復。出現的錯誤後應該第一時間展示出來，否則，這個問題在以後也會通過其它形式展示，這樣排錯的代價更高。
2 在程序運行發生問題時，開發人員，測試人員，最終用戶等能清楚的明白: 程序出問題了，在哪裏出了問題，出了什麼問題。
3 注意這裏說的“報告”並不一定就是非要把異常傳播到最高層打印到控制檯上，有時候可能只是記一條錯誤日誌，或是發送一條消息，電子郵件。[/size]


[size=large][color=blue]爲什麼實踐中大家(至少我是這樣)常常沒有遵守這一點[/color][/size]
[size=medium] 1 低級別選手對異常本身就含糊不清；
2 java的異常架構(受檢和非受檢)本身就有相當的爭議，個人認爲主要原因在於這種架構容易讓人誤用，包括JDK的開發者；
[color=red]注： Robert Martin也認爲受檢的異常並不好，主要原因是在異常向上傳播時，會讓每一個方法都受影響(每個方法的定義裏都必須拋出異常)，結果就是代碼耦合性強。條件允許的情況下，儘可能使用非受檢異常。[/color]
3 從一些書中可以找到一些好的實踐，但是系統性的，權威性的說明好像還沒有看到。[/size]


[size=large][color=blue]實踐做法[/color][/size]
[size=medium]1 普通的應用程序(如桌面應用)直接把異常往外層擴展。
2 如果自己做框架，儘量把異常包裝成unchecked exception，類似spring的做法，這樣就不用寫擴展代碼而把異常擴展到最高層。
3 在無法擴展異常到外層時(例如web應用)，捕獲異常後，通過各種方式，例如日誌，郵件來報告異常。
注： 實踐中，發郵件可能是個比較好的方案，例如： 可以對一段時間內發生的錯誤彙總起來，一起發給系統管理人員。如果只記日誌效果不一定好，一是錯誤可能淹沒在日誌裏，二是系統管理人員事情太多，不一定有這個精力去持續關注日誌。[/size]


[color=red]注：上面若干想法來自於<高效程序員的45個習慣>精簡版， effective java等書。如有雷同，不是巧合。另外，最近在看Robert Martin的<Clean Code>，看完後可能會有不同的觀點，到時再更新。[/color]