已檢查與未檢查的異常

Question

我研究過：但是，對於未經檢查的異常，編譯器不會強制客戶端程序員捕獲異常或在 throws 子句中聲明它。 事實上，客戶端程序員甚至可能不知道異常可能會被拋出。 例如，String 的charAt()方法拋出的StringIndexOutOfBoundsException 。

這是什么意思？

根據該代碼，無需將 try catch 塊放入代碼中，但我已經看到編譯器強制將代碼放入 try catch 塊中。

我很困惑他們到底是什么？

Answer 1

未經檢查的異常是那些擴展RuntimeException類的異常。 編譯器永遠不會強迫您捕獲此類異常或強迫您在方法中使用throws關鍵字聲明它。 檢查所有其他異常類型（不擴展RuntimeException ），因此必須聲明為被拋出和/或捕獲。

當您希望方法的調用者（即 API 的用戶）顯式處理 API 中的異常情況時，使用檢查的異常。 當您認為調用能夠對這種異常情況執行一些有意義的事情時，就會聲明檢查的異常，例如重試調用、回滾更改或將其轉換為一些用戶可讀的錯誤消息。

如果您認為該調用對異常沒有任何用處（尤其是當它表示錯誤或 API 的錯誤使用時），則應取消選中該異常。 此外，帶有太多已檢查異常的 API 可能會令人討厭（例如，嘗試使用 java 反射 API=）

Answer 2

• Checked Exceptions 對於處理程序正常操作中發生的事件很有用。 一個示例是在無法打開文件時引發的IOException 。 即使程序沒有任何問題，也會發生這些異常。 因此，有必要告訴程序如何處理異常。
• 未經檢查的異常對於識別代碼中的缺陷很有用。 例如，在null對象上讀取值時會引發NullPointerException 。 因此，未經檢查的異常表示需要程序員手動修復的問題。 為了避免錯誤行為，程序崩潰是合理的，因此不需要 try-catch 塊（但可能需要提供緩解措施，例如向用戶顯示錯誤）。

Answer 3

你的問題到底是什么？ 編譯器不應該（也不會）強制您嘗試/捕獲未經檢查的異常，這將違背它們的本質。

一般的想法是，檢查的異常是您可以預見的，但可能基於您無法控制且您必須處理的輸入。 未經檢查的異常通常代表程序中的錯誤。

有很多人認為檢查異常在 Java 平台中是一個錯誤，他們只是非常謹慎地使用它們或根本不使用它們。 你可以通過搜索谷歌閱讀更多關於這場辯論的信息。

Answer 4

這是因為，

1. 未經檢查的異常不是程序員錯誤的結果。 相反，它們是我們（程序員）不希望對其做太多事情的嚴重后果。
2. 對於Checked Exception，是由於程序員的錯誤而產生的異常，通常可以由程序員自己解決。

檢查以下鏈接：

為什么未選中運行時異常？
已檢查與未檢查的異常？

Answer 5

所有異常都是運行時間的一部分，而不是編譯時間。 有兩種異常檢查異常和未檢查異常。 已檢查異常的示例是 IO 異常、ClassNotFound 異常，未檢查異常的示例是運行時異常。 在檢查異常的情況下，錯誤或警告消息在編譯時出現，以便用戶在運行時使用 throws 關鍵字處理它，該關鍵字用於將異常拋出到默認的 catch 機制系統。 但是如果出現未經檢查的異常，編譯時不會出現警告。

Answer 6

**檢查異常

在編寫代碼期間要檢查或處理或應注意的異常稱為已檢查異常。 例如： 1. 我們有 FileNotFoundException --> 當我們編寫一些與文件類相關的代碼時會發生這種情況。 絕對有文件不存在的可能性。 在這種情況下，為了處理它們，我們肯定會被迫處理這些異常。 2. 還有一個例子是 ParseException ，它會在我們處理日期函數時發生。

未經檢查的異常

這些是在編碼期間可選處理的異常。 是否處理它們取決於我們。 如果我們未能處理它們，則在執行期間有可能出現運行時錯誤。 例如：我們有一個叫做 NullPointerException、ArithemeticException、NosSuchElementFoundException 等的東西。 這些就像我們甚至不必處理它們的可選事物。 甚至 jvm 或編譯器也不建議我們處理它們。**

Answer 7

簡單來說，

• 已檢查異常是那些可以並且應該由您的代碼處理的異常（因此編譯器會強制您處理它們）
• 未經檢查的異常是超出程序員控制范圍的異常（因此編譯器不會強迫您處理它們）

即使在創建自定義例外時也使用相同的規則。