什么時候應該檢查異常/未選中的異常？

Question

我從各種教程中學到了“如果可以合理地期望客戶端從異常中恢復，那么將其作為一個已檢查的異常。如果客戶端無法執行任何操作以從異常中恢復，請將其作為未經檢查的異常。”

我真的希望通過一些代碼示例看到之前語句的有效性。 例如

try {
        br.readLine();
    } catch (IOException e) {

        e.printStackTrace();
    }

在這里，IOException被檢查Exception.So，當這個異常發生時，我應該如何恢復？ 在這里，我排除了異常日志記錄，異常重新拋出任務，因為它們實際上並沒有恢復，即做正確的事情。 那么，應該在這里應用哪些修改來從中恢復？

如果有辦法從中恢復，那么可以將相同類型的方法應用於以下代碼：

 try{
    Integer.parseInt("ghg4");
 }catch(NumberFormatException nfe){   
   }

這里的NumberFormatException是一個運行時/未經檢查的異常。如果有辦法從中恢復，那么為什么它首先被聲明為運行時異常？

Answer 1

c＃消除了檢查異常，我認為這是一個好主意。

在我編寫的代碼中，我主要遵循c＃模式，從RuntimeException擴展所有內容。 然而，有一些地方我利用已檢查的異常來強制自己和任何使用我的代碼的人回應更多的“正常”異常情況

Answer 2

RuntimeException和Exception之間沒有明確的邊界。 一般來說，過度使用Exception的后代導致catch子句鏈（例如用於反射處理代碼）或者只catch (Exception e)而不關心特定類型。 有許多不同的實踐，這個問題是有爭議的 - 即它並不那么簡單，並且沒有唯一一種正確的方法來設計應用程序中的異常。

---

我遵守以下規則：

1. 如果異常將單獨處理並且可以與簡單的輸入數據錯誤或類似錯誤區分開來 - 那么它就是一個經過檢查的異常。

2. 如果異常是由明顯錯誤的輸入條件或代碼中的錯誤（如NPE）引起的 - 那么它就是運行時異常。

例如，從這個邏輯來看，我會將IOException作為RuntimeException的后代。

---

更新：關於IOException，這不是黑白分明的。 但是一些IOE后代（如FileNotFoundException，MalformedURLException等） - 肯定只是糟糕的輸入。 當你使用ByteArray IO Streams（或類似的）來處理從未發生過的IOE時，它會讓事情變得煩人。

Answer 3

我看到三種類型的例外。 在一個極端是您無法做任何事情，如NullPointerException。 您將在代碼中以非常高的級別處理此問題，或者根本不處理。 檢查它是荒謬的。

另一端是提供有意義信息的那些。 當方法已經具有返回值時，它們有點返回值，有時是復數值。 它們也是一種跳躍調用堆棧的簡單方法。 （我可以寫一本關於這個的書，但我會在這里停下來。）EOFException 應該是一個很好的例子。 文件有它們的目的，你遲早會打它，並且你不想每次閱讀都要檢查它。 在這種情況下，將調用已檢查的異常。 （我認為user1291492會就此與我達成一致。）它可能會發生，任何調用read方法的人都應該為此做好准備。 他們更喜歡編譯器錯誤而不是運行時錯誤。

現在，這種類型的異常，你不想把堆棧跟蹤！ 這需要很多時間。 調用者只需知道他打了一個EOF，而不是發生在IO系統的深處！ 此外，除非要返回有趣的信息，否則異常本身應該是final static引用，生成一次並用於發生的每個EOF。

中間的第三種類型是Java庫使用的類型，如真正的 EOFException。 他們毫無意義。 調用者期望永遠不會獲得EOF（例如，他將自己的標記放在那里）並且EOFException與NullPointerException具有相同的性質， 或者他期望它並且不需要堆棧的麻煩和丟失的處理時間跟蹤。 我認為問題在於Java設計者本身 - 而且我不得不承認在我考慮這個問題時自己也有這個問題 - 這很少 - 不確定這兩個類別中的哪兩個可能屬於這些例外。 即使在同一個程序中，在一個地方，EOFException也可能表示程序完全失敗。 在另一種情況下，可能是找出文件已被讀取的常規方法。 因此，最終的結果是大量的異常會同時執行這兩個作業並且做得很差，迫使程序員在他們無法做任何事情時使用try和catch並throws它們並將它們不需要的復雜堆棧跟蹤交給他們。

另外：我應該明確指出你可以通過簡單地接受你已經讀完文件並繼續執行來恢復真正的EOFException，可能在catch塊中有一個break語句。 但是，還有其他正確的方法來捕獲EOF，因此EOFException通常意味着像NullPointerException這樣的真正問題。 奇怪的是，我使用NumberFormatException的方式，我認為應該檢查。 當我想要一個數字時獲得“AAA”是非常常見的，用戶錯誤，而不是編程錯誤。