本篇內容主要講解“為什么不使用try-catch-finally處理Java異常”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“為什么不使用try-catch-finally處理Java異常”吧!
創新互聯主打移動網站、網站建設、成都網站設計、網站改版、網絡推廣、網站維護、國際域名空間、等互聯網信息服務,為各行業提供服務。在技術實力的保障下,我們為客戶承諾穩定,放心的服務,根據網站的內容與功能再決定采用什么樣的設計。最后,要實現符合網站需求的內容、功能與設計,我們還會規劃穩定安全的技術方案做保障。
一、前言
在正式分析之前,我們先看一波finally的執行順序。
1、finally不是必要條件
也就是說try-catch-finally中,可以只有try-catch,也可以只有try-finally。
2、假設基于try-catch-finally:
第一:代碼沒有異常
執行順序:try執行完整->catch不執行->finally執行
第二:代碼有異常且catch進行捕獲
執行順序:try執行部分->跳轉catch捕獲處理->finally執行
第三:代碼有異常且catch不捕獲:這種情況沒有catch
執行順序:try執行部分->finally執行
從上面的執行順序可以看出,finally語句不管在哪種情況是一定會執行的。基于這個認識,現在我們再來分析。
二、try-finally的缺點
先看案例,本案例來自《Effective java》,現在要關閉資源:
static String firstLineOfFile(String path) throws IOException { BufferedReader reader = new BufferedReader(new FileReader(path)); try { return reader.readLine(); } finally { reader.close(); } }
關閉一個資源還好,但是如果再添加第二個資源,代碼看起來就會一團糟了。
static void copy(String src, String desc) throws IOException { InputStream in = new FileInputStream(src); try { OutputStream out = new FileOutputStream(desc); byte[] bytes = new byte[1024]; int n; try { while ((n = in.read(bytes)) != -1) { out.write(bytes, 0, n); } } finally { out.close(); } } finally { in.close(); } }
如果需要關閉的資源不僅種類多,而且數量也很多。那代碼可就太龐大了。現在對這種方式的缺點進行一波總結:
1. 關閉的資源多事,代碼復雜
2. 對于第一個案例,如果設備出現異常,那么那么調用readLine就會拋出異常,同時close方法也出現異常,在這種情況下,close異常會完全抹去readLine異常。在異常堆棧軌跡中也完全沒有readLine異常的記錄。
現在來測試一邊:
基于以上原因,出現了try-with-resources。
三、try-with-resources的優勢
try-with-resources是在jdk1.7引入的,可以完美解決以上的問題。要使用這個構造的資源,必須先實現AutoCloseable接口,其中包含了單個返回void的close方法,Java類庫與第三方類庫中的許多類和接口,現在都實現或擴展了AutoCloseable接口,因此我們現在不必實現了。
既然try-with-resources能夠解決以上的問題,現在來看一下,如何解決的:
1、代碼復雜問題解決
static void copy(String src, String desc) throws IOException { try (InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(desc)) { byte[] bytes = new byte[1024]; int n; while ((n = in.read(bytes)) != -1) { out.write(bytes, 0, n); } } }
可以看出這種方式代碼更加簡單,出現了錯誤,也能快速定位。
2、異常抹去問題解決
static String firstLineOfFil (String path) throws IOException { try (BufferedReader reader = new BufferedReader(new FileReader(path))) { return reader.readLine(); } }
如果readLine和不可見的close方法都拋出異常,close方法拋出的異常就會被禁止,try-finally處理機制中我們無法看到,堆棧軌跡中也不能打印,但是try-with-resources不一樣,全部會被打印在堆棧軌跡中,并注明它們是被禁止的異常,通過編寫調用getSuppressed方法還可以訪問到它們。現在再來測試一遍。
OK,上面基本上全部分析完畢,但是此書還給出了一個更好的案例:
static String firstLineOfFile(String path, String defaultVal) { try (BufferedReader reader = new BufferedReader(new FileReader(path))) { return reader.readLine(); } catch (IOException e) { return defaultVal; } }
這個firstLineOfFile方法沒有拋出異常,但是如果它無法打開文件,或者無法從中讀取,就會返回一個默認值。
到此,相信大家對“為什么不使用try-catch-finally處理Java異常”有了更深的了解,不妨來實際操作一番吧!這里是創新互聯網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
當前題目:為什么不使用try-catch-finally處理Java異常
網站網址:http://vcdvsql.cn/article18/gghidp.html
成都網站建設公司_創新互聯,為您提供域名注冊、定制網站、靜態網站、搜索引擎優化、標簽優化、動態網站
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯