Java异常处理终结篇——如何进行Java异常处理设计
【本文轉自于Java異常處理終結篇——如何進行Java異常處理設計】
有一句這樣話：一個衡量Java設計師水平和開發團隊紀律性的好方法就是讀讀他們應用程序里的異常處理代碼。
本文主要討論開發Java程序時，如何設計異常處理的代碼，如何時拋異常，捕獲到了怎么處理，而不是講異常處理的機制和原理。
在我自己研究Java異常處理之前，我查過很多資料，翻過很多書藉，試過很多搜索引擎，換過很多英文和中文關鍵字，但是關于異常處理設計的文章實在太少，在我研究完Java異常處理之后，我面試過很多人，也問過很多老員工，極少碰到對Java異常有研究的人，看來研究這個主題的人很少，本文內容本是個人研究異常時做的筆記，現整理一下與大家一起分享。
首先我們簡單的回顧一下基礎知識，Java中有兩種異常，嚴格的說是三種，包含四個類，層次圖如下：
Throwable是一個可拋類，只有其子類可以被關鍵字throw拋出，請勿直接繼承本類，Error是表示系統級錯誤，如內存耗盡了，我們一般情況下不用管，Exception是所有異常的父類，所以他的子類，除了RuntimeException及其子類，是屬于編譯時異常，這種異常必須在代碼里被顯示的捕獲語句包住，否則編譯不過，而RuntimeException及其子類表示運行時異常，不強制要求寫出顯示的捕獲代碼，但如果沒有被捕獲到，則線程會被強制中斷。
我們主要關注后兩種，他們的特點已領教了，下面我們通過回答問題的方式來分析異常設計，在開始之前，請確保你已經知道使這兩種異常：
捕獲到了編譯時異常怎么處理：
這個話題恐怖是最古老的啦，網上的文章多數都是討論這個話題，但這些文章大部分只是給了幾條禁止的原則，他們是：1）不要直接忽略異常；2）不要用try-catch包住過多語句；3）不要用異常處理來處理程序的正常控制流；4）不要隨便將異常迎函數棧向上傳遞，能處理盡量處理。他們都對，但是要做異常處理的設計，信息還是不夠，比如第一條他只是告訴了不要忽略，但沒有告訴我們怎么處理，所以很多人直接e.printStackTrace()了，這種處理比直接忽略是好一點，但還不夠好。對于第二條，他的理由是避免耗資源很大，不過“過多語句”這句話描述的太模糊了，沒說明到底多少才算過多，以致于很多人的try-catch語句只包住會拋編譯時異常的那一行代碼，如果一段代碼中有多行代碼會拋編譯時異常，那這一段代碼中可能有多個try-catch語句塊，像這樣：
[java]?view plaincopy print?這樣有什么壞處呢，到處都是異常處理的代碼，很容易給人造成困惑，很難找出哪些是正常流程的代碼，而且還違背了Java異常機制的初衷，Java異常機制是為了把異常處理的代碼與正常流程的代碼分開，避免程序中出現過多的像傳統程序那樣的非法值判斷語句，以致于擾亂了正常流程。但上述代段充斥著try-catch語句塊，已經擾亂了主流程，并極大影響了可讀性。
try-catch既不能包太多代碼，又不能包太少，那應該包多少才適合呢，這個問題我查過的資料中都沒有提，我的個人建議是包住邏輯關系緊密的代碼，比如打開文件，讀取文件，關閉文件，我認為就是邏輯關系緊密的代碼，如果你發現包住的代碼很多，可以封裝一些方法，如讀取文件的代碼很長就應該封裝成一個方法，這個方法可以申明IOException，（其實讀文件的細節本來屬于低層邏輯，打開，讀取，關閉才屬于同層邏輯，如果讀取代碼很短，初期為了省事才不封成讀取細節的代碼，不過后期可以重構并封裝成方法，這是《重構·改善繼有的代碼設計》一書中的思想——軟件應該不斷的重構和加善）。這樣才能達到把異常代碼與正常流程代碼分離的目的。
第3）條沒問題，第4）條也有問題，“不要隨便”很模糊，那什么時候才能向上傳遞呢。
吐槽完了，我們現在來說說到底該如何處理捕獲到的編譯時異常：
一、恢復并繼續執行：這個結果是最完美的，也是編譯時異常出生的目的——捕獲異常，并恢復繼續執行程序。所以如果你捕獲了一個異常是先盡力恢復，這種情況其實就是在主方案行不通時，用備選方案，而且主方案能否行通不能事先知道，必須執行的時候才能知道，所以在一般情況下，備選方案比主方案要的運行結果要差。比如一個視頻程序，它要調用一個下載節目列表的方法，可能如下：
[java]?view plaincopy print?
二、向上傳播異常：向上傳播就是在本方法上用throws申明，本方法里的代碼不對某異常做任何處理。如果不能用上述恢復措施，就檢查能不能向上傳播，什么情況下可以向上傳播呢？有多種說法，一種說法是當本方法恢復不了時，這個說法顯然是錯誤，因為上層也不一定能恢復。另外還有兩種說法是：1.當上層邏輯可以恢復程序時；2.當本方法除了打印之外不能做任何處理，而且不確定上層能否處理。這種兩種說法都是正確的，但還不夠，因為也有的情況，明確知道上層恢復不了也需要上層處理，所以我認為正確的做法是：當你認為本異常應該由上層處理時，才向上傳播。不過這得根據你程序的設計來靈活思考，比如你的類設計了一個上層方法集中處理異常，而下層有一些private方法只是簡單的用throws申明。當上層方法捕獲到異常時，雖然不能恢復執行，但可以做一些處理，如轉換成便于閱讀的文本，或者用下面討論的轉譯。
三、轉譯異常：轉譯即把低層邏輯的異常轉化成為高層邏輯的異常，因為有可能低層邏輯的異常在高層邏輯中不能被理解，主要實現是新寫一個Exception的子類，然后在低層邏輯捕獲異常，改拋這個新寫的異常，比如剛剛那個視頻程序，他的主流程可能是：1.加載節目列表，2.顯示播放節目。而加載節目列表子流程又包含讀取節目文件、解析節目文件、顯示節目列表。而讀取節目文件有可能出現IO異常（有可能本地和網上的文件都讀不了了），解析節目文件可能出現解析異常，這時如果把這些異常，直接向上傳播，變成這樣，你覺得合理嗎：
[java]?view plaincopy print?
另外，主流程中還有一個播放流程也可以定義一個播放異常的類，再做這樣的轉譯處理，但是，如果流程多，是不是得寫多個異常類呢，有人建議是每個包定義一個異常類，但并不是絕對的，這個細粒度還要根據具體的程序邏輯來決定，這種把握能力就要靠經驗了，這可能就是架構師的過人之處了。
四、改拋為運行時異常：這個很好玩，也是一條很方便的處理手法（我常用，我用這個還發現了一個Android系統的bug），即當你捕獲到異常時，重新拋出，這跟轉譯很相似，有一點區別，這里拋的是運行時異常，而轉譯拋的是編譯時異常。那什么時候使用這個手法呢？簡單的說就是當某個異常出現時，你必須讓程序掛掉。解釋一下：如果某個異常情況一旦出現，程序便無法繼續執行，而且你明確知道本方法和上層邏輯做不出任何有意義的處理，你只能讓程序退出。所以你就拋一個運行時異常讓程序掛掉。舉個例子，比如在加密通信中，服務器捕獲到了一個非法數據異常，這是無法恢復的，而且就是拋一運行異常，讓線程掛掉，連接便會自動中斷。
五、記錄并消耗掉異常：這個手法就是把異常記錄下來（到文件或控制臺）然后忽略掉異常，有可能隨后就讓本方法返回null，這個手法一般用在不是很嚴重的異常，相當于是warning級別的錯誤，出現這個異常對程序的執行可能影響不太，比如程序的某個偏好設置文件（如窗口位置，最近文件等）損壞，但這個文件信息很少，程序只要使用默認配置即可。
有沒必要顯示捕獲運行時異常：
運行時異常一般是不需要捕獲的，因為它的目的就是讓程序在無法恢復時掛掉，但是也有特殊需求，比如你要收集所有的未捕獲異常記錄，可能用于統計，也可能用于將來調試。還有其它原因使你不想讓程序直接掛掉，比如你想把友好信息告訴用戶。
什么時候需要拋異常：
馬上就要討論如何拋異常了，但在必須先知道，什么時候需要拋異常，簡單的說就是遇到一個異常情況，這是一個模棱兩可的問題，就像美不美這個問題一樣，我幾種說法，你看你能理解哪一種，一種是正常情況的反面，即非正常情況，那什么是非正常情況呢，這也是仁者見仁，智者見智，比如說讀到文件尾，這個算正常還是異常呢，都說得過去，所以這里給一個判斷方法做為參考，如果是一個典型情況，就不當成是異常，所以讀到文件尾就沒有被當成一個異常，返回了-1。還有一種說法是，程序執行的必要條件不能成立，使得本方法無法繼續履行自己的職責。這兩種說法都不錯，你都可以用，而且覆蓋了大部分情況。
何時選用編譯時異常：編譯時異常是Java特有的，其它語言沒有，剛出來時很流行，所以你可以看到流處理包里充斥著IOException，但經過多年的使用，有人覺得編譯時異常是一種實驗性錯誤，應該完全丟棄，說這個話的人就是《Think In Java》的一書的作者Eckel，我認為這種說法太絕對了，關于這個是與否也有很大的爭論。《Effective Java》一書的作者則認為應避免不必要的編譯時異常，因為你拋編譯時異常會給強制要求調用者捕獲，這會增加他的負擔，我是這一觀點的支持者。那到底何時拋編譯時異常呢？當你發現一個異常情況時，檢查這兩個條件，為真時選用編譯時異常：一、如果調用者可以恢復此異常情況，二、如果調用者不能恢復，但能做出有意義的事，如轉譯等。如果你不確定調用者能否做出有意義的事，就別使編譯時異常，免得被抱怨。還有一條原則，應盡最大可能使用編譯時異常來代替錯誤碼，這條也是編譯時異常設計的目的。另外，必須注意使用編譯時異常的目的是為了恢復執行，所以設計異常類的時候，應提供盡量多的異常數據，以便于上層恢復，比如一個解析錯誤，可以在設計的異常類寫幾個變量來存儲異常數據：解析出錯的句子的內容，解析出錯句子的行號，解析出錯的字符在行中的位置。這些信息可能幫助調用恢復程序。
何時選用運行時異常：首先，運行時異常肯定是不可恢復的異常，否則按上段方法處理。這個不可恢復指的是運行時期不可恢復，如果可以修改源代碼來避免本異常的發生呢，那說明這是一個編程錯誤，對于編程錯誤，一定要拋運行時異常，編程錯誤一般可以通過修改代碼來永久性避免該異常，所以這種情況應該讓程序掛掉，相當于爆出一個bug，從而提醒程序員修改代碼。這種編程錯誤可以總結一下，API是調用者與實現者之間的契約，調用者必須遵守契約，比如傳入的參數不允許為空，這一點是隱含契約，沒必要明確寫出來的，如果違反契約，實現者就可以拋運行時異常，讓程序掛掉以提醒調用者。
其它情況是否應使用運行時異常，上面提到過，就是誰都無能為力的異常情況，還有就是你不確定到底能不能恢復，除此之外，你可以這樣判斷：如果你希望程序掛掉，就用運行時異常。需要說明的是，請盡量使用系統自帶異常，而不是新寫。網上還有一條建議是使用運行時異常時, 一定要將所有可能的異常寫進文檔。這認為只要把不常用的寫上即可，像NullPointException每個方法都有可能拋，但沒必要每個方法都寫說明。
將編譯時異常重構成運行時異常：
你可能手頭上有一份以前的代碼，大量的使有了編譯時異常，但很多都是沒有必要的編譯時異常，導致調用上不方便，《Effective Java》里有一種方法可以將編譯時異常轉為運行時異常：將原來拋編譯時異常的方法，拆成兩個方法，其中一個是用來指示異常是否為發生，即將以下代碼：
[java]?view plaincopy print?
UI層處理異常的注意點：
UI層和其下邏輯層的區別是UI層的出錯信息是被用戶看，而其下層邏層出錯信息是被程序員看到，用戶可不希望看一個打印的異常棧，更不希望程序無緣無故掛掉，用戶希望看到友好的提示信息。為到達這一目的，我們可以設一個屏障，屏障可以捕獲所有遺漏的異常，從而阻止程序直接掛掉，屏障當然恢復不了運行，但可以記錄錯誤便于日后調試，還可以輸出友好信息給用戶。Spring和Struts就有這樣的處理。
還有一點需要注意，用戶的傳入參數出現非法的概率很高，所以控制層接受到參數時一定要校驗，而不是原封不動的傳到其低層模塊。
經歷了一周的熬夜，總算把異常處理總結歸納成文了，但由于文章太長，肯定有一些錯誤和語言不精煉的地方，我會仔細檢察并及時改正，希望本文對大家有一定的幫助。
附錄
在我查過的資料中，以《Effective Java》書中對異常處理設計的研究得最系統，本文很多思想來自于它，下面我把其中的幾條原則翻譯（非直譯）并貼上：
第57條：只對異常情況使用異常。（說明：即不要用異常處理控制正常程序流）。
第58條：對可恢復異常使用編譯時異常，對編程錯誤使用運行時異常。
第59條：應避免不必要的編譯時異常：如果調用者即使合理的使用API也不能避免異常的發生，并且調用者可以對捕獲的異常做出有意義的處理，才使用編譯時異常。
第60條：應偏好使用自帶異常
第61條：拋出的異常應適合本層抽象（就是上面說的轉譯）
第62條：把方法可能拋的所有異常寫入文檔，包括運行時異常
第63條：用異常類記錄的信息要包含失敗時的數據
第64條：力求失敗是原子化的（解釋：就是如果調用一個方法發生了異常，就應該使對象返回調用前的狀態）
第65條：不要忽略異常
總結
以上是生活随笔為你收集整理的Java异常处理终结篇——如何进行Java异常处理设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【mysql】[error]group_
- 下一篇： SQL Server HA - 数据库镜