try-cache-finally讀取文件錯誤try-with-resources使用方法
引言
前些天項目經(jīng)理找到我說,阿杰,你過來一下,我這有個小方法,你幫我寫一下
- 需求: 提供一個文本文件,按行讀取,然后給出一個回調(diào)函數(shù),可以由調(diào)用者去實現(xiàn)對每行的處理.
我就想,你這不是瞧不起我嗎.5分鐘搞定!!嘴里卻說,你這個有點難,我需要研究下大概今天下班前能完成.
5分鐘過去了----> 代碼完成
摸魚3小時 ----> ok 代碼一發(fā),收工準備下班
public void clean2(String path, Consumer<String> consumer){
FileReader fileReader = null;
BufferedReader br = null;
try{
fileReader = new FileReader(path);
br = new BufferedReader(fileReader);
String line;
while((line = br.readLine()) != null ){
consumer.accept(line);
}
}catch (IOException e){
// do
}finally {
try {
if (br != null){
br.close();
}
if (fileReader != null){
fileReader.close();
}
} catch (IOException e) {
// do
}
}
}
項目經(jīng)理 ????????: 你tm明天別來了,自己去財務把這個月的結(jié)了,3行代碼就寫完的功能寫成這個鬼樣子.
那我就想啊,我寫的這么完美,那憑什么開除我,經(jīng)過我九九八十一天的苦思冥想,終于找到了問題的原因!!
try-cache-finally
try-finally 是java SE7之前我們處理一些需要關閉的資源的做法，無論是否出現(xiàn)異常都要對資源進行關閉。*
如果try塊和finally塊中的方法都拋出異常那么try塊中的異常會被抑制（suppress），只會拋出finally中的異常，而把try塊的異常完全忽略。
這里如果我們用catch語句去獲得try塊的異常，也沒有什么影響，catch塊雖然能獲取到try塊的異常但是對函數(shù)運行結(jié)束拋出的異常并沒有什么影響。
try-with-resources
try-with-resources語句能夠幫你自動調(diào)用資源的close()函數(shù)關閉資源不用到finally塊。
前提是只有實現(xiàn)了Closeable接口的才能自動關閉
public void clean(String path, Consumer<String> consumer) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
String line;
while((line = br.readLine()) != null ){
consumer.accept(line);
}
}
}
這是try-with-resources語句的結(jié)構(gòu)，在try關鍵字后面的( )里new一些需要自動關閉的資源。
這個時候如果方法 readLine 和自動關閉資源的過程都拋出異常，那么：
- 函數(shù)執(zhí)行結(jié)束之后拋出的是try塊的異常，而try-with-resources語句關閉過程中的異常會被抑制，放在try塊拋出的異常的一個數(shù)組里。（上面的非try-with-resources例子拋出的是finally的異常，而且try塊的異常也不會放在fianlly拋出的異常的抑制數(shù)組里）
- 可以通過異常的
public final synchronized Throwable[] getSuppressed()方法獲得一個被抑制異常的數(shù)組。 try塊拋出的異常調(diào)用getSuppressed()方法獲得一個被它抑制的異常的數(shù)組，其中就有關閉資源的過程產(chǎn)生的異常。
try-with-resources 語句能放多個資源,使用 ; 分割
try (
BufferedReader br = new BufferedReader(new FileReader(path));
ZipFile zipFile = new ZipFile("");
FileReader fileReader = new FileReader("");
) {
}
最后任務執(zhí)行完畢或者出現(xiàn)異常中斷之后是根據(jù)new的反向順序調(diào)用各資源的close()的。后new的先關。
try-with-resources 語句也可以有 catch 和 finally 塊
public void clean3(String path, Consumer<String> consumer){
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
System.out.println("RuntimeException 前");
int a = 1/0;
System.out.println("RuntimeException 后");
}catch (RuntimeException e){
System.out.println("拋出 RuntimeException");
}catch (IOException e){
System.out.println("拋出 RuntimeException");
}finally {
System.out.println("finally");
}
}
RuntimeException 前
拋出 RuntimeException
finally
以上就是try-cache-finally讀取文件錯誤try-with-resources使用方法的詳細內(nèi)容，更多關于try-with-resources讀取文件的資料請關注腳本之家其它相關文章！
相關文章
sentinel?整合spring?cloud限流的過程解析
這篇文章主要介紹了sentinel?整合spring?cloud限流,本文通過實例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-03-03
這篇文章主要介紹了Spring中@Transactional用法詳細介紹的相關資料,需要的朋友可以參考下2017-02-02
SpringBoot深入分析webmvc和webflux的區(qū)別
這篇文章主要介紹了SpringBoot深入分析webmvc和webflux的區(qū)別，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習吧2023-02-02
之前在公司內(nèi)其它團隊找到幫忙排查的一個后端服務連接超時問題,問題的表現(xiàn)是服務部署到線上后出現(xiàn)間歇性請求響應非常慢（大于10s）,但是后端業(yè)務分析業(yè)務日志時卻沒有發(fā)現(xiàn)慢請求,所以本文給大家介紹了Java后端服務間歇性響應慢的問題排查與解決,需要的朋友可以參考下2025-03-03
當IDEA啟動命令過長時,可以通過修改workspace.xml文件或調(diào)整啟動類配置來解決,方案一是在.idea文件或項目目錄中修改workspace.xml；方案二是通過運行配置（run->edit）來保存啟動設置,這兩種方法都可以有效縮短命令長度,解決啟動錯誤2024-09-09
這篇文章主要介紹了springboot請求找不到路徑異常的問題及解決方案，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-01-01
這篇文章主要介紹了拳皇Java簡單小程序，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-03-03
淺析Java如何優(yōu)雅的設計接口狀態(tài)碼和異常
HTTP協(xié)議里定義了一系列的狀態(tài)碼用來表明請求的狀態(tài),如常用的200表示請求正常,404表示請求的資源不存在,所以本文就來和大家討論一下如何優(yōu)雅的設計接口狀態(tài)碼和異常,感興趣的可以了解下2024-03-03
單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。這篇文章主要為大家介紹了C語言實現(xiàn)單元測試的方法，需要的可以參考一下2022-11-11
反射主要解決動態(tài)編程,即使用反射時,所有的對象生成是動態(tài)的,因此調(diào)用的方法也是動態(tài)的.反射可以簡化開發(fā),但是代碼的可讀性很低2013-05-05