throws 關鍵字僅用于檢查異常。它指示調用者使用 try catch 塊通過 throws 關鍵字排除所有列出的異常。既然我們知道我們的模塊中可能會發生什么樣的檢查異常，那么：為什么我們不在模塊內部使用 try catch 塊來處理已檢查的異常？我們可以使用 try-catch 塊處理模塊內部的檢查異常嗎？如果 (2) 的答案是肯定的，那么為什么我們使用 throws 關鍵字強制調用者排除那些異常，而我們可以在模塊本身內部排除相同的異常？這樣我們就不需要在每次調用方法時手動排除異常。
4 回答
一只斗牛犬
TA貢獻1784條經驗 獲得超2個贊
讓我以FileInputStream::new投擲FileNotFoundException為例來澄清你的誤解。
因此，例如我們有這樣的代碼：
FileInputStream fis = new FileInputStream("/some/path/to/file.txt");那可能會拋出一個FileNotFoundException，而你是說，
FileInputStream明明知道要拋出aFileNotFoundException，為什么不自己處理呢？
因為FileInputStream不知道如何處理異常！
根據情況，有很多方法可以處理FileNotFoundException：
如果文件路徑來自用戶輸入，您可能會要求用戶輸入另一個文件路徑
您可能會顯示一條錯誤消息
你可能什么都不做，就讓它崩潰
根據情況，以上所有都是完全明智的選擇。怎么FileInputStream會知道你的情況？它不是！
這就是為什么它用一個throws子句說：
我拋出這些異常，你自己處理。
蝴蝶刀刀
TA貢獻1801條經驗 獲得超8個贊
這都是關于如何從異常中恢復的。例如
java.lang.File，當文件不存在時應該做什么？因為它不知道什么對被叫方最好，所以它讓被叫方處理這種情況當然，如果清楚應該如何處理上述異常，則可以在模塊中處理異常。如果處理依賴于被調用者或上下文，則讓調用函數決定
現在應該清楚了
當年話下
TA貢獻1890條經驗 獲得超9個贊
請注意，您還可以重新拋出異常。在許多情況下，將錯誤傳遞給下一層是完全合理的。如果您還throws IOException向您的方法添加 a，則它不必處理它。在許多情況下，處理此類故障的唯一方法就是失敗，而這通常應該在最外層完成。
IDE 會提醒您遺漏throws并建議解決此問題的可能方法。因此，與定義失敗行為的好處相比，開發人員的工作量非常小。
然而應該清楚的是，IDE 不是編譯器可以預測未來，或者適當的抽象。
首先，接口或抽象方法可以——也應該——聲明異常。例如：
interface Opener {
InputStream open(String id) throws IOException;
}
提醒該接口的用戶處理此類錯誤，例如文件未找到異常。
此外，編譯器或 IDE 不知道正確的抽象。你的代碼可能會做一個
if (httpcode == 404)
throw new FileNotFoundException("Server returned a 404 error.");
但是您還不知道您以后是否會將其更改為不同的異常，因為它實際上并不是一個文件。例如，您可能希望有一個網絡異常的子類。但是，您可以確定您打算拋出的所有異常都是IOExceptions，因此需要該方法的用戶在此級別處理它。
開心每一天1111
TA貢獻1836條經驗 獲得超13個贊
有時您想在應用程序的另一部分管理一些異常。
例如，您可以有一個只向互聯網發送請求并帶回響應的包。如果您在無外設服務器應用程序和具有用戶界面的桌面應用程序中將此包用作 lib，則您需要以不同方式管理 to 異常。記錄它并重試無頭應用程序并顯示錯誤消息和桌面應用程序的重試按鈕。
如果你只在 net 包中管理異常，你就不能有這個，如果你拋出異常，應用程序的其余部分可以根據需要處理它。
這里還有其他用例，如果您不知道您的包裹將如何使用（這樣您或其他人可以選擇以后如何處理它），這可能很有用
總體思路是分離純代碼邏輯和異常管理。
添加回答
舉報
0/150
提交
取消