Mr_李強

如果 Java 方法不能按照正常的流程執行，那麼可以通過另外一種途徑退出：拋出一個封裝了錯誤信息的對象，這個就是 Java 的異常；當發生異常時，後面的代碼無法繼續執行，而是由異常處理器繼續執行。

01. 異常的分類

Throwable 是所有異常的超類，下一級可以分為 Error 和 Exception ：

1. Error

Error 是指 Java 運行時系統內部的錯誤，或者說它代表了 JVM 本身的錯誤，通常都是比較嚴重的錯誤， 比如內存溢出, 虛擬機錯誤等等；

Error 通常和硬件或 JVM 有關，和程序本身無關，所以不能被代碼捕獲和處理。

2. Exception

我們經常說的異常是指 Exception，又可以分成運行時異常和檢查異常。

RuntimeException：運行時異常，這類異常在編譯期間不強制代碼捕捉，但是可能在在 JVM 運行期間拋出異常；出現此類異常，通常是代碼的問題，所以需要修改程序避免這類異常。常見的運行時異常，比如：NullPointerException、ClassCastException 等等。

CheckedException：檢查異常，這種異常發生在編譯階段，Java 編譯器會強制代碼去捕獲和處理此類異常；比如：ClassNotFoundException、IllegalAccessException 等等。

02. 異常的處理方法

捕獲異常使用 try...catch 語句，把可能發生異常的代碼放到 try {...} 中，然後使用 catch 捕獲對應的異常；

我們也可以在代碼塊中使用 Throw 向上級代碼拋出異常；

在方法中使用 throws 關鍵字，向上級代碼拋出異常；

03. Throw 和 throws 的區別

Throw 在方法內，後面跟著異常對象；而 throws 是用在方法上，後面跟異常類；

Throw 會拋出具體的異常對象，當執行到 Throw 的時候，方法內的代碼也就執行結束了；throws 用來聲明異常，提醒調用方這個方法可能會出現這種異常，請做好處理的準備，但是不一定會真的出現異常。

04. 如何優雅地處理異常

1. 不要試圖通過異常來控制程序流程，比如開發一個接口，正確的做法是對入參進行非空驗證，當參數為空的時候返回“參數不允許為空”，而不應該捕捉到空指針的時候返回錯誤提示。

2. 僅捕獲有必要的代碼，儘量不要用一個 try...catch 包住大段甚至整個方法內所有的代碼，因為這樣會影響 JVM 對代碼進行優化，從而帶來額外的性能開銷。

3. 很多程序員喜歡 catch(Exception e)，其實應該儘可能地精確地指出是什麼異常。

4. 不要忽略異常，捕捉到異常之後千萬不能什麼也不做，要麼在 catch{...} 中輸出異常信息，要麼通過 Throw 或 throws 拋出異常，讓上層代碼處理。

5. 儘量不要在 catch{...} 中輸出異常後，又向上層代碼拋出異常，因為這樣會輸出多條異常信息，而且它們還是相同的，這樣可能會產生誤導。

6. 不要在 finally{...} 中寫 return，因為 try{...} 在執行 return 之前執行 finally{...} ，如果 finally{...} 中有 return，那麼將不再執行 try{...} 中的return。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

Java中異常提供了一種識別及響應錯誤情況的一致性機制，有效地異常處理能使程序更加健壯、易於調試。異常之所以是一種強大的調試手段，在於其回答了以下三個問題：

• 什麼出了錯?
• 在哪出的錯?
• 為什麼出錯?

在有效使用異常的情況下，異常類型回答了“什麼”被拋出，異常堆棧跟蹤回答了“在哪“拋出，異常信息回答了“為什麼“會拋出，如果你的異常沒有回答以上全部問題，那麼可能你沒有很好地使用它們。有三個原則可以幫助你在調試過程中最大限度地使用好異常，這三個原則是：

• 具體明確
• 提早拋出
• 延遲捕獲

為了闡述有效異常處理的這三個原則

明確異常

捕 獲異常時儘量明確也很重要。例如：如下可以通過重新詢問用戶文件名來處理FileNotFoundException，對於 EOFException，它可以根據異常拋出前讀取的信息繼續運行。

通過使用多個catch塊來給用戶提供捕獲到異常的明確信息。舉例來說：如果捕獲了FileNotFoundException，它可以提示用戶指定另一 個文件，某些情況下多個catch塊帶來的額外編碼工作量可能是非必要的負擔，但在這個例子中，額外的代碼的確幫助程序提供了對用戶更友好的響應。

儘早拋出異常

異常堆棧信息提供了導致異常出現的方法調用鏈的精確順序，包括每個方法調用的類名，方法名，代碼文件名甚至行數，以此來精確定位異常出現的現場。

java.lang.NullPointerException

以 上展示了FileInputStream類的open()方法拋出NullPointerException的情況。不過注意 FileInputStream.close()是標準Java類庫的一部分，很可能導致這個異常的問題原因在於我們的代碼本身而不是Java API。所以問題很可能出現在前面的其中一個方法，幸好它也在堆棧信息中打印出來了。

不幸的是，NullPointerException是Java中信息量最少的（卻也是最常遭遇且讓人崩潰的）異常。它壓根不提我們最關心的事情：到底哪裡是null。所以我們不得不回退幾步去找哪裡出了錯。

通過逐步回退跟蹤堆棧信息並檢查代碼，我們可以確定錯誤原因是向readPreferences()傳入了一個空文件名參數。既然readPreferences()知道它不能處理空文件名，所以馬上檢查該條件：

通過提早拋出異常（又稱＂迅速失敗＂），異常得以清晰又準確。堆棧信息立即反映出什麼出了錯（提供了非法參數值），為什麼出錯（文件名不能為空值），以及哪裡出的錯（readPreferences()的前部分）。這樣我們的堆棧信息就能如實提供：

另外，其中包含的異常信息（＂文件名為空＂）通過明確回答什麼為空這一問題使得異常提供的信息更加豐富，而這一答案是我們之前代碼中拋出的NullPointerException所無法提供的。

通過在檢測到錯誤時立刻拋出異常來實現迅速失敗，可以有效避免不必要的對象構造或資源佔用，比如文件或網絡連接。同樣，打開這些資源所帶來的清理操作也可以省卻。

延遲捕獲

菜鳥和高手都可能犯的一個錯是，在程序有能力處理異常之前就捕獲它。Java編譯器通過要求檢查出的異常必須被捕獲或拋出而間接助長了這種行為。自然而然的做法就是立即將代碼用try塊包裝起來，並使用catch捕獲異常，以免編譯器報錯。

問 題在於，捕獲之後該拿異常怎麼辦？最不該做的就是什麼都不做。空的catch塊等於把整個異常丟進黑洞，能夠說明何時何處為何出錯的所有信息都會永遠丟失。把異常寫到日誌中還稍微好點，至少還有記錄可查。但我們總不能指望用戶去閱讀或者理解日誌文件和異常信息。讓readPreferences()顯示錯誤信息對話框也不合適，因為雖然JCheckbook目前是桌面應用程序，但我們還計劃將它變成基於HTML的Web應用。那樣的話，顯示錯誤對話框顯然不是個選擇。同時，不管HTML還是C/S版本，配置信息都是在服務器上讀取的，而錯誤信息需要顯示給Web瀏覽器或者客戶端程序。

readPreferences()應當在設計時將這些未來需求也考慮在內。適當分離用戶界面代碼和程序邏輯可以提高我們代碼的可重用性。

那麼在最外層捕獲異常，統一處理：

Spring統一處理異常

如果是是Spring框架，可以使用Spring的統一異常處理機制，其他異常統統都拋出異常

這裡有一個目的就是在最上層處理業務邏輯的異常，這一條規則是明確異常（可以自定義異常來明確），儘早拋出異常，延遲捕獲異常。

冰魄秋雨

既然談到了優雅，那我默認是已經瞭解了異常的基本概念以及異常的分類。

以下純個人看法，如若雷同，就你是抄我的！

1.在方法裡面跳出定義的異常（該異常有具體的檢查性）

public void test() throws Exception_A Exception_B

{

//建議使用方式

}

public void test() throws exception

{

//low B 方式

}

為什麼low?檢查性異常的目的是什麼？聲明方法可能拋出的檢查性異常，如果只有這樣的檢查性異常，那應該包裝到自己的異常中並且添加信息。

2.千萬別捕Throwable類

因為Java Error也是Throwable的子類，而Error是虛擬機本身無法處理的，對於某些虛擬機的實現，虛擬機可能甚至不會再Error上去用catch。總而言之這是一個更嚴重的麻煩。

3.不想寫了，也不知道有沒有人看。有人看再更。

4.吐槽：悟空問答就沒有markdown嗎？寫點code真費勁。

關鍵字: 優雅 科技 異常