您何時更願意聲明異常而不是在Java中處理異常？

Question

我知道如果我們希望它由調用方法處理，我們可以為我們的方法聲明異常。 如果封閉方法拋出IOException，這甚至允許我們執行諸如寫入OutputStream之類的操作而不將代碼包裝在try / catch塊中。

我的問題是：任何人都可以提供一個實例，通常在您希望調用方法來處理異常而不是當前方法的地方嗎？

編輯：我的意思是在最后一行調用方法而不是超類。

Answer 1

一般來說，我會說設計你的異常流程，以便實際采取適當行動的代碼捕獲異常 。

這通常意味着在“庫”方法（或大型項目中的某種通用實用方法）中，您將拋出異常而不是捕獲它們。

另一方面，如果你有一種情況，你發現你自己聲明你的方法拋出一個你認為在實踐中幾乎不會發生的異常（例如序列化通常涉及各種虛假檢查異常，實際上不會發生，例如如果你對Integer進行反序列化，那么Integer類不太可能存在，但是你仍然必須捕獲相應的異常），然后你有第三個選項重新轉換為RuntimeException。

Answer 2

我想通過“超類”你的意思是調用你的方法的代碼。

如果您希望調用者比您的方法更了解問題，那么您可以將此任務傳遞給調用堆棧。

一般來說，如果您不知道如何處理問題，請不要。 以太傳遞它或將其包裝在另一個異常中。

Answer 3

如果你不能以合理的方式處理錯誤（例如顯示錯誤信息，采取替代路徑，等等），那么就讓它冒泡。

Answer 4

如果您希望在應用程序的不同級別處理錯誤。

這是一個半具體的例子。 假設我有一個Web應用程序，它是作為一系列狀態和操作實現的 。 假設在處理狀態時，數據庫訪問會導致SQLException 。 在我的應用程序正常運行期間不會發生這種情況; 只有在數據庫出現問題時才會發生這種情況。

訪問數據庫的方法不需要知道我處理半致命錯誤的程序是什么。 該邏輯在更高級別實現 - 在處理狀態的方法中 - 並且對於任何運行時錯誤本質上都是相同的，無論它是否真的是RuntimeException ：向用戶吐出一個好看的錯誤消息，告訴他們聯系tech支持。

想象一下，如果我必須添加一個try / catch塊來執行這個邏輯到每個訪問數據庫的方法，並可能拋出一個SQLException 。 這就是所謂的nightmare 。

Answer 5

我使用了考試作為在應用程序的架構層之間傳遞信息的一部分。

例如：
如果DAO（數據庫訪問層）獲得SQLException，它會拋出一個自定義的DAOLayerException，它被業務層捕獲，而業務層又拋出一個由表示層捕獲的異常。
這是針對未經檢查的例外情況。

如果函數要由多個調用者使用或在函數開發時未知，我通常會遵循拋出已 檢查的 未檢查異常（不處理它們）的做法。

Answer 6

在Web框架（如spring）中，您經常讓錯誤傳播，容器將處理它們（通過向用戶顯示錯誤頁面或消息，回滾事務等）。

此外，還有很多你從未捕獲的java錯誤，比如OutOfMemoryError。 你可以抓住它們，但是你無法正確處理它們。

Answer 7

你問了一個例子，這是一個常見的例子。

如果要編寫代碼來讀取特定的文件格式，這些通常會聲明IOException。 原因是它可能被桌面應用程序（想要放置對話框）或文本實用程序（想要編寫錯誤消息）或Web應用程序（想要返回錯誤代碼）使用。 異常處理允許您這樣做。

Answer 8

是的，我會聲明它，所以它傳播直到一個父調用方法實際上處理它（顯示在UI，打破那里，...）

對於Instance，我可能在sendEmail方法中有一些幫助方法。 如果幫助方法說checkEmailAddress（）產生異常，我希望sendEmail知道它，它可以進一步傳播它或在UI上發出警告“電子郵件是錯誤的”