4 回答

TA貢獻1829條經驗 獲得超7個贊
這個問題其實無須過多困擾。也沒有必要往JDK1.7的try-with-resources上扯。
首先關閉資源放在try塊里一定會有問題:資源可能不被關閉。
所以資源的關閉應該放在finally里,這沒有什么疑問。
至于finally塊里close資源會額外引入IOE
,這也是無法避免的。
目前(就我見到過的)絕大多數代碼里,捕獲IOE
后,最多打一條log,更多的是noop,即no operations,do nothing。
close的時候IOE發生的幾率很小,它應該屬于一種操作系統層面的error,選擇忽略它是正確的選擇,畢竟你的系統不能因為一個資源關閉錯誤而停止運行。況且,如果你硬要捕獲這個IOE,那能做些什么呢。
如果不想在finally塊里引入try-catch,我見過guava的一種關閉方式,寫個工具方法叫做closeQuietly(),不吵不鬧就挺好。

TA貢獻1875條經驗 獲得超3個贊
同意1樓的答案,你補充的問題,也是由于IDE的問題。
另外對于實現了 AutoCloseable 和 Closeable 接口的資源,最好都使用 try-with-resources結構。
以你的代碼作為例子,省略了一些代碼
try{
reader.readline();
}catch(IOException e){
e.printStackTrace();
}finally {
try {
reader.close();
} catch (IOException e) {
e.printStackTrace();
}
}
假設 readline 和 close 都發生io異常,使用 JDK1.7 前的異常捕捉結構,只能捕捉到 close 的異常,readline 的異常被抑制了。(因為 finally 的代碼必須執行)
另外一個問題,在 try-with-resources 中資源的 AutoCloseable 的 close 方法什么時候執行?
在執行完 try 代碼塊的代碼之后就會執行(這里不貼實驗代碼了),所以使用 try-with-resources 的結構,catch 塊和 finally 塊都是在資源進行關閉之后才會執行的。
添加回答
舉報