這次不用遠程 review 了，因為我們公司也復工了。這次 review 的代碼仍然是小王的，他編寫的大部分代碼都很漂亮，嚴謹的同時註釋也很到位，這令我非常滿意。但當我看到他沒用 try-with-resources 時，還是忍不住破口大罵：“我擦，你丫的竟然還在用 try–catch-finally！”
來看看代碼吧。
<code>public class Trycatchfinally {
public static void main(String[] args) {
BufferedReader br = null;
try {
br = new BufferedReader(new FileReader("/牛逼.txt"));
String str = null;
while ((str =br.readLine()) != null) {
System.out.println(str);
}
} catch (IOException e) {
e.printStackTrace();
} finally {
if (br != null) {
try {
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}/<code>咦，感覺這段代碼很完美無缺啊，try–catch-finally 用得中規中矩，尤其是文件名 牛逼.txt 很亮。不用寫註釋都能明白這段代碼是幹嘛的：在 try 塊中讀取文件中的內容，並一行一行地打印到控制檯。如果文件找不到或者出現 IO 讀寫錯誤，就在 catch 中捕獲並打印錯誤的堆棧信息。最後，在 finally 中關閉緩衝字符讀取器對象 BufferedReader，有效杜絕了資源未被關閉的情況下造成的嚴重性能後果。
在 Java 7 之前，try–catch-finally 的確是確保資源會被及時關閉的最佳方法，無論程序是否會拋出異常。
但是呢，有經驗的讀者會從上面這段代碼中發現 2 個嚴重的問題：
1）文件名“牛逼.txt”包含了中文，需要通過 java.net.URLDecoder 類的 decode() 方法對其轉義，否則這段代碼在運行時鐵定要拋出文件找不到的異常。
2）如果直接通過 new FileReader("牛逼.txt") 創建 FileReader 對象，“牛逼.txt”需要和項目的 src 在同一級目錄下，否則同樣會拋出文件找不到的異常。但大多數情況下，（配置）文件會放在 resources 目錄下，便於編譯後文件出現在 classes 目錄下，見下圖。
為了解決以上 2 個問題，我們需要對代碼進行優化：
<code>public class TrycatchfinallyDecoder {
public static void main(String[] args) {
BufferedReader br = null;
try {
String path = TrycatchfinallyDecoder.class.getResource("/牛逼.txt").getFile();
String decodePath = URLDecoder.decode(path,"utf-8");
br = new BufferedReader(new FileReader(decodePath));
String str = null;
while ((str =br.readLine()) != null) {
System.out.println(str);
}
} catch (IOException e) {
e.printStackTrace();
} finally {
if (br != null) {
try {
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}/<code>運行這段代碼，程序就可以將文件中的內容正確輸出到控制檯。但如果你對“整潔”這個詞心生嚮往的話，會感覺這段代碼非常臃腫，尤其是 finally 中的代碼，就好像一個灌了 12 瓶雪花啤酒的大肚腩。
網上看到一幅 Python 程序員調侃 Java 程序員的神圖，直接 copy 過來（侵刪），逗你一樂：
況且，try–catch-finally 至始至終存在一個嚴重的隱患：try 中的 br.readLine() 有可能會拋出 IOException，finally 中的 br.close() 也有可能會拋出 IOException。假如兩處都不幸地拋出了 IOException，那程序的調試任務就變得複雜了起來，到底是哪一處出了錯誤，就需要花一番功夫，這是我們不願意看到的結果。
為了模擬上述情況，我們來自定義一個類 MyfinallyReadLineThrow，它有兩個方法，分別是 readLine() 和 close()，方法體都是主動拋出異常。
<code>class MyfinallyReadLineThrow {
public void close() throws Exception {
throw new Exception("close");
}
public void readLine() throws Exception {
throw new Exception("readLine");
}
}/<code>然後我們在 main() 方法中使用 try-finally 的方式調用 MyfinallyReadLineThrow 的 readLine() 和 close() 方法：
<code>public class TryfinallyCustomReadLineThrow {
public static void main(String[] args) throws Exception {
MyfinallyReadLineThrow myThrow = null;
try {
myThrow = new MyfinallyReadLineThrow();
myThrow.readLine();
} finally {
myThrow.close();
}
}
}/<code>運行上述代碼後，錯誤堆棧如下所示：
<code>Exception in thread "main" java.lang.Exception: close
at com.cmower.dzone.trycatchfinally.MyfinallyOutThrow.close(TryfinallyCustomOutThrow.java:17)
at com.cmower.dzone.trycatchfinally.TryfinallyCustomOutThrow.main(TryfinallyCustomOutThrow.java:10)/<code>
readLine() 方法的異常信息竟然被 close() 方法的堆棧信息吃了，這必然會讓我們誤以為要調查的目標是 close() 方法而不是 readLine()——儘管它也是應該懷疑的對象。
但自從有了 try-with-resources，這些問題就迎刃而解了，只要需要釋放的資源（比如 BufferedReader）實現了 AutoCloseable 接口。有了解決方案之後，我們來對之前的 finally 代碼塊進行瘦身。
<code>try (BufferedReader br = new BufferedReader(new FileReader(decodePath));) {
String str = null;
while ((str =br.readLine()) != null) {
System.out.println(str);
}
} catch (IOException e) {
e.printStackTrace();
}/<code>你瞧，finally 代碼塊消失了，取而代之的是把要釋放的資源寫在 try 後的() 中。如果有多個資源（BufferedReader 和 PrintWriter）需要釋放的話，可以直接在 () 中添加。
<code>try (BufferedReader br = new BufferedReader(new FileReader(decodePath));
PrintWriter writer = new PrintWriter(new File(writePath))) {
String str = null;
while ((str =br.readLine()) != null) {
writer.print(str);
}
} catch (IOException e) {
e.printStackTrace();
}/<code>
如果你想釋放自定義資源的話，只要讓它實現 AutoCloseable 接口，並提供 close() 方法即可。
<code>public class TrywithresourcesCustom {
public static void main(String[] args) {
try (MyResource resource = new MyResource();) {
} catch (Exception e) {
e.printStackTrace();
}
}
}
class MyResource implements AutoCloseable {
@Override
public void close() throws Exception {
System.out.println("關閉自定義資源");
}
}/<code>代碼運行後輸出的結果如下所示：
<code>關閉自定義資源/<code>
是不是很神奇？我們在 try () 中只是 new 了一個 MyResource 的對象，其他什麼也沒幹，但偏偏 close() 方法中的輸出語句執行了。想要知道為什麼嗎？來看看反編譯後的字節碼吧。
<code>class MyResource implements AutoCloseable {
MyResource() {
}
public void close() throws Exception {
System.out.println("關閉自定義資源");
}
}
public class TrywithresourcesCustom {
public TrywithresourcesCustom() {
}
public static void main(String[] args) {
try {
MyResource resource = new MyResource();
resource.close();
} catch (Exception var2) {
var2.printStackTrace();
}
}
}/<code>咦，編譯器竟然主動為 try-with-resources 進行了變身，在 try 中調用了 close() 方法。
接下來，我們在自定義類中再添加一個 out() 方法，
<code>class MyResourceOut implements AutoCloseable {
@Override
public void close() throws Exception {
System.out.println("關閉自定義資源");
}
public void out() throws Exception{
System.out.println("沉默王二，一枚有趣的程序員");
}
}/<code>這次，我們在 try 中調用一下 out() 方法：
<code>public class TrywithresourcesCustomOut {
public static void main(String[] args) {
try (MyResourceOut resource = new MyResourceOut();) {
resource.out();
} catch (Exception e) {
e.printStackTrace();
}
}
}/<code>再來看一下反編譯的字節碼：
<code>public class TrywithresourcesCustomOut {
public TrywithresourcesCustomOut() {
}
public static void main(String[] args) {
try {
MyResourceOut resource = new MyResourceOut();
try {
resource.out();
} catch (Throwable var5) {
try {
resource.close();
} catch (Throwable var4) {
var5.addSuppressed(var4);
}
throw var5;
}
resource.close();
} catch (Exception var6) {
var6.printStackTrace();
}
}
}/<code>這次，catch 塊中主動調用了 resource.close()，並且有一段很關鍵的代碼 var5.addSuppressed(var4)。它有什麼用處呢？當一個異常被拋出的時候，可能有其他異常因為該異常而被抑制住，從而無法正常拋出。這時可以通過 addSuppressed() 方法把這些被抑制的方法記錄下來。被抑制的異常會出現在拋出的異常的堆棧信息中，也可以通過 getSuppressed() 方法來獲取這些異常。這樣做的好處是不會丟失任何異常，方便我們開發人員進行調試。
哇，有沒有想到我們之前的那個例子——在 try-finally 中，readLine()方法的異常信息竟然被 close() 方法的堆棧信息吃了。現在有了 try-with-resources，再來看看作用和 readLine() 方法一致的 out() 方法會不會被 close() 吃掉。
在 close() 和 out() 方法中直接拋出異常：
<code>class MyResourceOutThrow implements AutoCloseable {
@Override
public void close() throws Exception {
throw new Exception("close()");
}
public void out() throws Exception{
throw new Exception("out()");
}
}/<code>調用這 2 個方法：
<code>public class TrywithresourcesCustomOutThrow {
public static void main(String[] args) {
try (MyResourceOutThrow resource = new MyResourceOutThrow();) {
resource.out();
} catch (Exception e) {
e.printStackTrace();
}
}
}/<code>程序輸出的結果如下所示：
<code>java.lang.Exception: out()
at com.cmower.dzone.trycatchfinally.MyResourceOutThrow.out(TrywithresourcesCustomOutThrow.java:20)
at com.cmower.dzone.trycatchfinally.TrywithresourcesCustomOutThrow.main(TrywithresourcesCustomOutThrow.java:6)
Suppressed: java.lang.Exception: close()
at com.cmower.dzone.trycatchfinally.MyResourceOutThrow.close(TrywithresourcesCustomOutThrow.java:16)
at com.cmower.dzone.trycatchfinally.TrywithresourcesCustomOutThrow.main(TrywithresourcesCustomOutThrow.java:5)/<code>
瞧，這次不會了，out() 的異常堆棧信息打印出來了，並且 close() 方法的堆棧信息上加了一個關鍵字 Suppressed。一目瞭然，不錯不錯，我喜歡。
總結一下，在處理必須關閉的資源時，始終優先考慮使用 try-with-resources，而不是 try–catch-finally。前者產生的代碼更加簡潔、清晰，產生的異常信息也更靠譜。答應我好不好？別再用 try–catch-finally 了。
閱讀更多 Java的小本家 的文章
