為什麼開發人員反對 Java 中的檢查異常？

反對 checked 異常

許多年來，我無法對以下問題獲得一個滿意的答案：為什麼有些開發者如此反對 checked 異常？我進行了許多對話、閱讀部落格文章，閱讀了 Bruce Eckel 的觀點（他說了反對 checked 異常的第一人）。

我目前正在編寫一些新程式碼，並且非常注意處理異常的方式。我試圖了解「我們不喜歡 checked 異常」的人群的觀點，但我仍然無法理解。

我所進行的每一次對話最終都是以同樣的尚未解決的問題結束的……讓我來闡述一下：

一般而言（根據Java 的設計），

• 錯誤是用於永遠不應該捕獲的事情（VM對花生過敏，有人不小心在它上面撒了一罐花生）
• 運行時異常是用於程式設計師做錯的事情（程式設計師越界使用數組）
• 異常（運行時異常除外）是用於超出程式設計師控制的事情（檔案系統中寫入檔案時磁碟已滿，進程的檔案句柄數量限制已達到，無法再開啟檔案）
• 可拋出物件只是所有異常類型的父類。

我常聽到的一個論點是，如果發生了異常，那麼開發人員所要做的就是退出程式。

我聽到的另一個常見論點是，checked 異常使重構程式碼變得更加困難。

對於「我就退出」的論點，即使你退出，仍然需要顯示一條合理的錯誤訊息。如果你只是在錯誤處理方面拖延，那麼你的用戶在程式不帶明確退出原因退出時不會過於高興。

對於「它使重構變得困難」的人群，這表明未選擇適當的抽象層級。與其宣告一個方法拋出 IOException，應將 IOException 轉換為更適合正在進行的事情的例外。

我不會針對包裝Main 的catch(Exception)（或在某些情況下為catch(Throwable) 而抓狂，它可以確保程式能優雅退出，但我總要捕獲我需要的特定異常。

如果你拋出 RuntimeException
子類而不是 Exception
子類，你怎麼知道
應該捕獲什麼？

如果答案是捕捉 Exception，那麼你還在以與系統異常相同的方式處理程式設計師錯誤。那在我看來是錯的。

如果捕獲 Throwable，那麼你還在以相同的方式處理系統異常和 VM 錯誤（及類似錯誤）。那在我看來是錯的。

如果答案是只捕捉你知道拋出的異常，那麼你如何知道拋出了哪些異常？當程式設計師 X 拋出一個新異常並忘記捕獲它時會發生什麼？在我看來，這很危險。

我想說，會顯示堆疊追蹤的訊息是錯的。不喜歡 checked 異常的人不覺得這樣嗎？

所以，如果你不喜歡 checked 異常，你能否解釋一下為什麼不，而且請回答那個沒有得到回答的問題。

我並不是在尋求關於何時使用這兩種模型的建議，我正在尋找為什麼 人們從RuntimeException 擴展而不是從Exception 擴展，以及/或他們在捕獲異常後重新拋出RuntimeException 而不是向方法添加throws 的原因。我希望了解人們不喜歡 checked 異常的動機。

以上是為什麼開發人員反對 Java 中的檢查異常？的詳細內容。更多資訊請關注PHP中文網其他相關文章！