【注】本文譯自：Java Exceptions - DZone Java
Java Exception
Java Exception 是為處理異常應用程序行為而創建的類。在本文中，我將解釋如何使用 Java Exception 類以及如何在考慮現有 Java Exceptions 設計的情況下創建異常結構。Java 異常概念是 Java 中的重要里程碑之一，每個開發人員都必須瞭解它。
Java 異常結構比你想象的要有用
Java 異常的結構非常有用，可以告訴開發人員一組重要的事情（如果開發人員正確使用此結構）。所以，在這裏，您可以看到基本結構：
可以捕獲所有可能情況的主要父類是 Throwable，它有 2 個子類：Error 和 Exception。
Java Error
Java Error 代表異常情況。一旦出現錯誤，應用程序可能會關閉。
Java Exception
與錯誤不同，Java 異常有機會從問題中恢復應用程序，並嘗試保持應用程序運行。異常也分為兩類：
異常由運行時和非運行時異常表示，也稱為已檢異常。此分類與錯誤異常非常相似，但在該分類中，已檢異常在恢復方面更為樂觀。
已檢和未檢異常
在 Java 中，有兩種類型的異常。已檢異常迫使開發人員創建處理程序異常或重新拋出它們。如果重新拋出已檢查的異常，則 java 函數必須在其簽名中聲明它。未檢異常 unline checked 不需要任何處理。 這樣的設計意味着無法處理未經檢查的異常，並且註定會被拋出到頂級父類。
Error 異常調查
有兩種方法可以處理拋出的異常：在當前方法中處理它或者只是重新拋出它。沒有比這更好的方法了：您可能有一個父處理程序或以某種方式處理它，例如創建重試邏輯。
好的、壞的、醜的
介紹完之後，我們可以將所有異常分為 3 組：Checked、Runtime 和 Error。主要思想是，他們每個人都會陷入不同的情況。最樂觀的是 Checked 異常。運行時將屬於恢復機會很小的情況。而且，最悲觀的是Error。
Checked, Runtime, Error ... 然後呢?
瞭解異常類的類型後，我們可能會回答下一個問題：
- 情況有多糟糕，問題的原因是什麼。
- 如何解決這個問題。
- 我們需要重啓 JVM 嗎？
- 我們需要重寫代碼嗎？
知道異常類，我們可以預測可能出錯的地方。考慮潛在的原因，我們可以假設問題的原因是什麼以及如何解決它。讓我們回顧一下最流行的場景，看看這些異常可以告訴我們什麼。在接下來的段落中，我們將回顧著名的異常並調查潛在的代碼是什麼。在我們的調查中，我們假設應用程序足夠穩定並且開發階段已經完成和測試。
Error 異常調查
我們從最悲觀的案例或我們的醜男開始。Error 真的有那麼醜嗎？ 讓我們來看看最常見的 Java 錯誤：
因此，在大多數情況下，您需要做的就是更改 JVM 配置或添加缺少的依賴項。仍然存在需要更改代碼的情況，但它們不太可能在每種情況下應用更改。
Checked 異常調查
對於受檢異常，我們期望有機會恢復問題；例如，再試一次。在這一部分，我們回顧最著名的已檢異常。提供的例外可能是彼此的父類，但是，在這裏，我只列出最常見的案例，而不關心它們的關係：
好吧，有很多異常，但是，正如我所承諾的，我把最常見的異常放在這裏。那麼，這張表説明了什麼？如果我們查看最可能的原因，我們會發現其中的大多數不僅不需要任何代碼更改，甚至不需要重新啓動應用程序。所以，顯然，已檢異常應該是好人。
Runtime 異常調查
最常見也是個人最悲觀的例外：運行時。Checked 和 Error 異常錯誤不會導致任何代碼更改。但是，在大多數情況下，運行時異常突出了代碼中的真正問題，如果不重寫代碼就無法修復這些問題。讓我們通過查看最流行的運行時異常來找出原因：
一個例子可能給人的印象是任何運行時異常都會導致應用程序失敗。在大多數情況下，這是正確的，因為不更改代碼就無法恢復應用程序。最終，運行時異常是我們的壞人，它會導致新的代碼更改、開發人員的壓力和業務損失。
些許批評
在這次審查期間，我們做出了一個重大假設：代碼已準備好投入生產並經過充分測試。但是，在實踐中，這很難實現。所以，我們所做的結論並不是100% 可靠，但是代碼越穩定，結果就越真實。
已檢異常和代碼污染
根據已檢查異常，設計開發人員必須使所有可恢復的異常都是可檢查的。因此，每次調用帶有已檢查異常簽名的方法都會為 Try Catch 結構添加 3-4 行。這種方法使代碼變得醜陋且可讀性較差。就個人而言，我更喜歡使用運行時異常。即使在設計庫的情況下，您仍然可以在方法簽名中保留運行時異常，並在 API 中添加一些註釋。在這種情況下，您的 API 用户將能夠決定如何處理它。
