填坑，整理下Java的常用異常。正確使用異常在實際編碼中非常重要，但面試中的意義相對較小，因為對異常的理解和應用很難通過幾句話或幾行程式碼考查出來，不過我們至少應答出三點：異常類的繼承關係、常用異常類、常用異常類的使用場景，下文將圍繞這三點介紹。
異常類的繼承關係
Java中，所有異常都繼承自Throwable類（一個完整可用的類）。整體上分為Error、Exception兩個大類，Exception大類又分為UncheckedException（繼承於RuntimeException）和CheckedException（繼承於Exception，但不繼承於RuntimeException）。
為了幫助理解，我在每個類別下都給出了兩個常用子類，如Error包括OutOfMemoryError、AssertionError等；UncheckedException包括NullPointerException、IllegalArgumentException；CheckedException包括IOException、InterruptedException。面試畫異常類的繼承關係時，要求能清楚的說明幾個類別並分類別舉幾個常用的異常類。
常用異常類
下面分類別擴充一下常用的異常類，字典序排序：
| 類別 | 常用異常類 |
|---|---|
| Error | AssertionError、OutOfMemoryError、StackOverflowError |
| UncheckedException | AlreadyBoundException、ClassCastException、ConcurrentModificationException、IllegalArgumentException、IllegalStateException、IndexOutOfBoundsException、JSONException、NullPointerException、SecurityException、UnsupportedOperationException |
| CheckedException | ClassNotFoundException、CloneNotSupportedException、FileAlreadyExistsException、FileNotFoundException、InterruptedException、IOException、SQLException、TimeoutException、UnknownHostException |
需要著重理解的是UncheckedException。
上述異常類都是很常見的，但其中幾個異常類設計的不好，需要注意：
- ConcurrentModificationException：實現“快速失敗”的機制，但實際上，“快速失敗”機制本身仍然無法保證併發環境下安全性，參考原始碼|從原始碼分析非執行緒安全集合類的不安全迭代器。因此，雖然該異常很常見，不要去依賴它。
- JSONException：常見於json字串解析失敗的情況，但遮蔽了大量的失敗細節，往往很難根據該異常作出處理。如果專案中大量使用json，建議使用第三方的json解析庫，如gson等。
- UnsupportedOperationException：這是一種編碼上的惡性妥協，經常在抽象類的成員方法中被使用者主動丟擲，表示該方法還未實現等，但由於是UncheckedException，執行期才能夠發現，完全無益於編碼期間的安全性。自己編碼時儘量不要使用。
- SQLException：與JSONException原因相似，但其遮蔽的失敗細節範圍更廣。同時，SQLException還是一個CheckedException，在不能解決問題的情況下，又使程式碼變的臃腫不堪。建議同。如果做Java Web開發，熱門的ORM庫都能解決上述問題。
常用異常類的使用場景
常用異常還是有點多，下面分別講解上述三個類別的使用場景，並在每個類別中選一個例子進行講解。
Error
Error通常描述了系統級的錯誤，並且程式猿無法主動處理——當然，系統級錯誤也有可能由程式碼間接導致，這不在我們的討論範圍內。發生系統級錯誤的時候，系統環境已經不健康了，因此，Error不強制捕獲或宣告，也就是不強制處理，一般情況下只需要把異常資訊記錄下來（如果能記下當時的系統快照更好）。
OutOfMemoryError
當可用記憶體不足時，會由JVM丟擲OutOfMemoryError。一般由三種原因導致：
- 堆設定過小，不滿足正常的記憶體需求
- 程式碼中存在記憶體洩露，佔用了大量記憶體而不能被回收
- 選擇的GC演算法與某些極端的應用場景不匹配，記憶體碎片過多，沒有足夠大的連續空間分配給物件
JVM丟擲OutOfMemoryError前，會嘗試進行一次Full GC，如果GC後可用記憶體還是不足，才會丟擲OutOfMemoryError。因此，這時程式猿必然無法主動處理這一問題，只能等程式崩潰後再去查證原因。
查證OutOfMemoryError的技巧足以單開一篇文章了，本文不作深入。
UncheckedException
嚴格來說，Error也可以被劃歸UncheckedException，但我們更習慣用UncheckedException描述執行期發生，通常由於程式碼問題直接引起的程式相關的錯誤，並且程式猿無法主動處理。注意區分，系統級錯誤都應該用Error描述。UncheckedException發生的大部分情況是程式碼寫挫了，因此，UncheckedException也不強制捕獲或宣告，也就是不強制處理，一般情況下記下日誌即可。
不同的是，如果可能，要保證UncheckedException是可控的（在異常被動丟擲前檢查並主動丟擲）。
JSONException就是不可控的。
NullPointerException
NullPointerException是最常見的UncheckedException。如果在一個空指標上引用方法或變數等，則執行期會丟擲NullPointerException。空指標讓程式變的不可控：如果任由空指標在程式執行期隨意傳遞、使用，我們將無法確定程式的行為，也無法確定捕獲NullPointerException時程式所處的狀態。
解決這一問題的方法很簡單：
- 儘早檢查並主動丟擲異常
- 單獨、提前處理邊界條件
- 儘量不使用null表示狀態，特別是在集合中
前兩條原則通用於大部分UncheckedException，可參考String#toLowerCase()的例子。第三條原則需要在程式碼的健壯與簡潔之間做出權衡，優先保證簡潔清晰，需要健壯再去健壯。
CheckedException
猴子對CheckedException的理解不到位，如果各位有更好的理解希望能交流一下。以下講猴子“不到位”的理解。
CheckedException描述了外部環境導致的不太嚴重的錯誤，程式猿應該主動處理。注意與系統級錯誤區分，系統級錯誤通常是不可恢復的。因此，CheckedException強制捕獲或宣告，程式猿必須處理。記錄日誌，包裝後再次丟擲，在方法簽名中宣告，是三種最常見的做法。
同UncheckedException一樣，CheckedException也要保證是可控的。對CheckedException的可控性要求更高，不僅要主動檢查，還要在捕獲到異常時，作出合適的處理。
不過，猴子認為大量CheckedException的存在就是個錯誤。比如FileAlreadyExistsException，更應該由使用者主動檢查發現，而不應該依賴於異常。對於可以處理的異常，本質上相當於控制流問題，用異常去表達反而讓控制流變模糊。不過有時候猴子寫小專案，也會為了簡化程式碼，直接將相關異常宣告在方法簽名中，並一路宣告幹到main方法。恩，everything is a trade-off。
IOException
產生IOException的原因非常多，但很多時候我們並不關心細節原因，因為檔案系統是一個不太可控的因素，這時我們可以以IOException為粒度處理；某些需要關心細節的異常情況，則應使用IOException的子類，以分情況處理。
前面總結的FileAlreadyExistsException、FileNotFoundException、UnknownHostException等，都是IOException的子類。這三種異常恰好都是可以處理的。
挖坑，InterruptedException也相當重要，後面要專門寫一篇來整理。
總結
實際的編碼工作中，我們應正確的使用異常表達程式碼設計，並儘可能使用JDK提供的異常類。JDK內建了非常多的異常類，我們只需要掌握一些常用的異常類，然後舉一反三。
本文連結：Java常用異常整理
作者：猴子007
出處：monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議釋出，歡迎轉載，演繹或用於商業目的，但是必須保留本文的署名及連結。