Java中的異常處理：高級特性和類型
譯文譯者 | 李睿
審校 | 重樓
Java平臺包含了多種語言特性和庫類型，用于處理與預期程序行為不同的異常。本文將介紹Java中異常處理的高級特性，其中包括堆棧跟蹤（stack traces）、異常鏈（exception chaining）、try-with-resources、多重捕獲（multi-catch）、最終重新拋出異常（final re-throw），以及堆棧遍歷（stack walking）。
Java教程的學習內容
以下將介紹在Java程序中處理異常的高級特性：
- 堆棧跟蹤和堆棧跟蹤元素
- 原因(Causes)和異常鏈（exception chaining）
- Try-with-resources
- 多重捕獲(multi-catch)
- 最終重新拋出異常（final re-throw）
- StackWalking和StackWalking API
使用堆棧跟蹤進行異常處理
每個JVM線程(執行路徑)都與創建線程時創建的堆棧相關聯。這個數據結構被劃分為幀（frame），這些幀是與方法調用相關聯的數據結構。因此，每個線程的堆棧通常被稱為方法調用堆棧。
每當調用一個方法時，就會創建一個新的幀。每幀存儲局部變量、參數變量(保存傳遞給方法的參數)、返回到調用方法的信息、存儲返回值的空間、在調度異常時有用的信息等等。
堆棧跟蹤是在線程執行過程中某個時間點的活動堆棧幀的報告。Java的Throwable類（在Java.lang包中）提供了打印堆棧跟蹤、填充堆棧跟蹤和訪問堆棧跟蹤元素的方法。
下載本教程中示例的源代碼。
打印堆棧跟蹤
當throw語句拋出一個throwable時，它首先會在當前執行的方法中查找一個合適的catch塊。如果沒有找到，它會回溯方法調用堆棧，尋找能夠處理該異常的最近的catch塊。如果仍然沒有找到，JVM將終止執行，并顯示一條合適的消息。可以在清單1中看到這一行為。
清單1.PrintStackTraceDemo.java (version 1)
import java.io.IOException;
public class PrintStackTraceDemo
{
public static void main(String[] args) throws IOException
{
throw new IOException();
}
}清單1的示例創建了一個java.io.IOException對象，并將該對象拋出main()方法。因為main()不處理這個throwable，而且main()是頂級方法，因此JVM會終止執行，并顯示一條合適的消息。對于這個應用程序，將看到以下消息：
Exception in thread "main" java.io.IOException
at PrintStackTraceDemo.main(PrintStackTraceDemo.java：7)JVM通過調用Throwable的void printStackTrace()方法輸出這條消息，該方法在標準錯誤流上打印調用throwable對象的堆棧跟蹤。輸出的第一行顯示了調用throwable對象的toString()方法的結果。下一行顯示了fillInStackTrace（）之前記錄的數據（稍后討論）。
其他的打印堆棧跟蹤方法
throwable的重載void printStackTrace(PrintStream ps)和void printStackTrace(printwwriter pw)方法將堆棧跟蹤輸出到指定的流或寫入器。
堆棧跟蹤顯示了創建throwable的源文件和行號。在本例中，它是在PrintStackTrace.java源文件的第7行創建的。
可以直接調用printStackTrace()，通常是調用catch塊。例如，考慮PrintStackTraceDemo應用程序的第二個版本。
清單2. PrintStackTraceDemo.java (version 2)
import java.io.IOException;
public class PrintStackTraceDemo
{
public static void main(String[] args) throws IOException
{
try
{
a();
}
catch (IOException ioe)
{
ioe.printStackTrace();
}
}
static void a() throws IOException
{
b();
}
static void b() throws IOException
{
throw new IOException();
}
}清單2展示了一個main()方法，它調用方法a()，而方法a()又調用方法b()。方法b()向JVM拋出一個IOException對象，JVM將展開方法調用堆棧，直到找到main()的catch塊，該塊可以處理異常。異常是通過對throwable調用printStackTrace()來處理的。這種方法產生以下輸出：
java.io.IOException
at PrintStackTraceDemo.b(PrintStackTraceDemo.java：24)
at PrintStackTraceDemo.a(PrintStackTraceDemo.java：19)
at PrintStackTraceDemo.main(PrintStackTraceDemo.java：9)printStackTrace()不會輸出線程的名稱。與其相反，它首先會在第一行調用 Throwable 對象的 toString() 方法，以返回異常的完全限定類名（如 java.io.IOException），這是輸出的第一部分。然后輸出方法調用層次結構：最近調用的方法(b())位于頂部，main()位于底部。
堆棧跟蹤標識的是哪一行?
堆棧跟蹤標識了創建throwable的行，但它不會標識拋出throwable的行(通過throw)，除非拋出和創建是在同一行代碼中完成的。
填充堆棧跟蹤
throwable聲明了一個Throwable fillInStackTrace()方法來填充執行堆棧跟蹤。在調用Throwable對象中，它記錄有關當前線程堆棧幀的當前狀態的信息。考慮清單3。
清單3. FillInStackTraceDemo.java (version 1)
import java.io.IOException;
public class FillInStackTraceDemo
{
public static void main(String[] args) throws IOException
{
try
{
a();
}
catch (IOException ioe)
{
ioe.printStackTrace();
System.out.println();
throw (IOException) ioe.fillInStackTrace();
}
}
static void a() throws IOException
{
b();
}
static void b() throws IOException
{
throw new IOException();
}
}清單3和清單2的主要區別在于catch塊的throw (IOException) ioe.fillInStackTrace()；聲明。該語句替換ioe的堆棧跟蹤，然后重新拋出throwable。應該看到這樣的輸出：
java.io.IOException
at FillInStackTraceDemo.b(FillInStackTraceDemo.java：26)
at FillInStackTraceDemo.a(FillInStackTraceDemo.java：21)
at FillInStackTraceDemo.main(FillInStackTraceDemo.java：9)
Exception in thread "main" java.io.IOException
at FillInStackTraceDemo.main(FillInStackTraceDemo.java：15)第二個堆棧跟蹤顯示ioe.fillInStackTrace（）的位置，而不是重復標識IOException對象創建位置的初始堆棧跟蹤。
Throwable構造函數和fillInStackTrace()
throwable的每個構造函數都調用fillInStackTrace()。然而，當將false傳遞給writableStackTrace時，下面的構造函數(在JDK 7中引入)不會調用這個方法：
Throwable(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace)
fillInStackTrace()調用一個原生方法，該方法沿著當前線程的方法調用堆棧遍歷以構建堆棧跟蹤。這種遍歷代價高昂，如果過于頻繁，可能會影響性能。
如果遇到性能非常關鍵的情況(可能涉及嵌入式設備)，可以通過重寫fillInStackTrace()來阻止堆棧跟蹤的構建。請查看清單4。
清單4. FillInStackTraceDemo.java (version 2)
{
public static void main(String[] args) throws NoStackTraceException
{
try
{
a();
}
catch (NoStackTraceException nste)
{
nste.printStackTrace();
}
}
static void a() throws NoStackTraceException
{
b();
}
static void b() throws NoStackTraceException
{
throw new NoStackTraceException();
}
}
class NoStackTraceException extends Exception
{
@Override
public synchronized Throwable fillInStackTrace()
{
return this;
}
}清單4引入了NoStackTraceException。這個自定義檢查的異常類重寫fillInStackTrace（）以返回This——對調用Throwable的引用。該程序生成以下輸出：
NoStackTraceException注釋掉覆蓋的fillInStackTrace()方法，會看到以下輸出：
NoStackTraceException
at FillInStackTraceDemo.b(FillInStackTraceDemo.java：22)
at FillInStackTraceDemo.a(FillInStackTraceDemo.java：17)
at FillInStackTraceDemo.main(FillInStackTraceDemo.java：7)訪問堆棧跟蹤的元素
有時，需要訪問堆棧跟蹤的元素，以便提取日志記錄、識別資源泄漏源和其他目的所需的詳細信息。printStackTrace()和fillInStackTrace()方法不支持這個任務，但是java.lang.StackTraceElement和它的方法就是為這個任務設計的。
stacktraceelement類描述了在堆棧跟蹤中表示堆棧幀的元素。它的方法可用于返回類的完全限定名，該類包含這個堆棧跟蹤元素所表示的執行點以及其他有用信息。以下是該類的主要方法：
- String getClassName()返回包含這個堆棧跟蹤元素所表示的執行點的類的完全限定名。
- String getFileName()返回包含這個堆棧跟蹤元素所表示的執行點的源文件的名稱。
- int getLineNumber()返回包含這個堆棧跟蹤元素所表示的執行點的源行的行號。
- String getMethodName()返回包含這個堆棧跟蹤元素所表示的執行點的方法的名稱。
- 當包含這個堆棧跟蹤元素所表示的執行點的方法是原生方法時，boolean isNativeMethod() 返回true。
另一個重要方法是java.lang.Thread和Throwable類上的StackTraceElement[]getStackTrace（）。這個方法分別返回一個堆棧跟蹤元素數組，表示調用線程的堆棧轉儲，并提供對printStackTrace（）打印的堆棧跟蹤信息的程序化訪問。
清單5展示了StackTraceElement和getStackTrace()。
清單5. StackTraceElementDemo.java (version 1)
import java.io.IOException;
public class StackTraceElementDemo
{
public static void main(String[] args) throws IOException
{
try
{
a();
}
catch (IOException ioe)
{
StackTraceElement[] stackTrace = ioe.getStackTrace();
for (int i = 0; i < stackTrace.length; i++)
{
System.err.println("Exception thrown from " +
stackTrace[i].getMethodName() + " in class " +
stackTrace[i].getClassName() + " on line " +
stackTrace[i].getLineNumber() + " of file " +
stackTrace[i].getFileName());
System.err.println();
}
}
}
static void a() throws IOException
{
b();
}
static void b() throws IOException
{
throw new IOException();
}
}當運行這個應用程序時，會看到以下輸出：
Exception thrown from b in class StackTraceElementDemo on line 33 of file StackTraceElementDemo.java
Exception thrown from a in class StackTraceElementDemo on line 28 of file StackTraceElementDemo.java
Exception thrown from main in class StackTraceElementDemo on line 9 of file StackTraceElementDemo.java最后，在Throwable類上有setStackTrace()方法。這種方法是為遠程過程調用(RPC)框架和其他高級系統設計的，允許客戶端覆蓋在構造Throwable時由fillInStackTrace()生成的默認堆棧跟蹤。
之前展示了如何重寫fillInStackTrace()以防止構建堆棧跟蹤。然而，可以使用StackTraceElement和setStackTrace()來安裝新的堆棧跟蹤。可以創建一個通過以下構造函數初始化的StackTraceElement對象數組，并將該數組傳遞給setStackTrace()：
StackTraceElement(String declaringClass, String methodName, String fileName, int lineNumber)清單6演示了StackTraceElement和setStackTrace()。
清單6 . StackTraceElementDemo.java (version 2)
public class StackTraceElementDemo
{
public static void main(String[] args) throws NoStackTraceException
{
try
{
a();
}
catch (NoStackTraceException nste)
{
nste.printStackTrace();
}
}
static void a() throws NoStackTraceException
{
b();
}
static void b() throws NoStackTraceException
{
throw new NoStackTraceException();
}
}
class NoStackTraceException extends Exception
{
@Override
public synchronized Throwable fillInStackTrace()
{
setStackTrace(new StackTraceElement[]
{
new StackTraceElement("*StackTraceElementDemo*",
"b()",
"StackTraceElementDemo.java",
22),
new StackTraceElement("*StackTraceElementDemo*",
"a()",
"StackTraceElementDemo.java",
17),
new StackTraceElement("*StackTraceElementDemo*",
"main()",
"StackTraceElementDemo.java",
7)
});
return this;
}
}采用星號包圍了StackTraceElementDemo類名，以證明這個堆棧跟蹤是輸出的跟蹤。運行應用程序，將觀察到以下堆棧跟蹤：
NoStackTraceException
at *StackTraceElementDemo*.b()(StackTraceElementDemo.java：22)
at *StackTraceElementDemo*.a()(StackTraceElementDemo.java：17)
at *StackTraceElementDemo*.main()(StackTraceElementDemo.java：7)原因和異常鏈
在異常處理中，一個catch塊經常會通過拋出另一個異常來響應捕獲到的異常。第一個異常被認為是導致第二個異常發生的原因，這兩個異常被隱式地鏈接在一起。
例如，調用庫方法的catch塊時可能會出現內部異常，而該內部異常對標準庫方法的調用者不應該是可見的。因為需要通知調用者出現了錯誤，所以catch塊會創建一個符合庫方法合約接口的外部異常，并且調用者可以處理這個異常。
由于內部異常可能對于診斷問題非常有幫助，catch塊應該將內部異常包裝在外部異常中。被包裝的異常被稱為“原因”（cause），因為它的存在導致拋出外部異常。此外，包裝的內部異常（原因）被顯式地鏈接到外部異常。
對原因和異常鏈的支持是通過兩個Throwable構造函數(以及對應的exception、RuntimeException和Error)和兩種方法提供的：
- Throwable(String message, Throwable cause)
- Throwable(Throwable cause)
- Throwable getCause()
- Throwable initCause(Throwable cause)
Throwable構造函數(及其對應的子類)允許在構造Throwable時包裝原因。如果處理的教學法遺留代碼的自定義異常類不支持任何一個構造函數，可以通過在Throwable上調用initCause()來包裝原因。需要注意的是，initCause()只能被調用一次。無論哪種方式，都可以通過調用getCause()返回原因。當沒有原因時，這個方法返回null。
清單7 展示了一個名為 CauseDemo 的應用程序，該應用程序演示了異常原因（以及異常鏈）的概念。
清單7. CauseDemo.java
public class CauseDemo
{
public static void main(String[] args)
{
try
{
Library.externalOp();
}
catch (ExternalException ee)
{
ee.printStackTrace();
}
}
}
class Library
{
static void externalOp() throws ExternalException
{
try
{
throw new InternalException();
}
catch (InternalException ie)
{
throw (ExternalException) new ExternalException().initCause(ie);
}
}
private static class InternalException extends Exception
{
}
}
class ExternalException extends Exception
{
}清單7顯示了CauseDemo、Library和ExternalException類。CauseDemo的main()方法調用Library的externalOp()方法并catch其拋出的ExternalException對象。catch塊調用printStackTrace()來輸出外部異常及其原因。
庫的externalOp()方法故意拋出一個InternalException對象，其catch塊將該對象映射到一個ExternalException對象。因為ExternalException不支持可以接受cause參數的構造函數，所以使用initCause()來包裝InternalException對象。
運行這個應用程序，就會看到下面的堆棧跟蹤：
ExternalException
at Library.externalOp(CauseDemo.java：26)
at CauseDemo.main(CauseDemo.java：7)
Caused by： Library$InternalException
at Library.externalOp(CauseDemo.java：22)
... 1 more第一個堆棧跟蹤顯示，外部異常起源于Library的externalOp()方法(CauseDemo.java中的第26行)，并在第7行對該方法的調用中拋出。第二個堆棧跟蹤顯示了內部異常原因源自Library的externalOp()方法(CauseDemo.java中的第22行)。... 1 more行表示第一個堆棧跟蹤的最后一行。如果可以刪除這一行，將看到以下輸出：
ExternalException
at Library.externalOp(CauseDemo.java：26)
at CauseDemo.main(CauseDemo.java：7)
Caused by： Library$InternalException
at Library.externalOp(CauseDemo.java：22)
at CauseDemo.main(CauseDemo.java：7)可以通過改變ee.printStackTrace(); to來證明第二個跟蹤的最后一行是第一個堆棧跟蹤的最后一行的副本。
ee.getCause().printStackTrace();.關于“...more””以及探究原因鏈的更多信息
通常，“...n more”這樣的表述意味著原因的堆棧跟蹤的最后n行與前一個堆棧跟蹤的最后n行是重復的。
這個例子只揭示了一個原因。然而，從非簡單的現實世界應用程序中拋出的異常可能包含由多個原因構成的復雜鏈。可以通過使用如下所示的循環來訪問這些原因：
catch (Exception exc)
{
Throwable t = exc.getCause();
while (t != null)
{
System.out.println(t);
t = t.getCause();
}
}Try-with-resources
Java應用程序經常訪問文件、數據庫連接、套接字和其他依賴于相關系統資源的資源(例如文件句柄)。系統資源的稀缺性意味著它們最終必須被釋放，即使在發生異常時也是如此。當系統資源沒有被釋放，應用程序在嘗試獲取其他資源時最終會失敗，因為沒有更多相關的系統資源可用。
在對異常處理基礎的介紹中，提到資源(實際上是它們所依賴的系統資源)在finally塊中釋放。這可能會導致冗長的樣板代碼，例如下面顯示的文件關閉代碼：
finally
{
if (fis != null)
try
{
fis.close();
}
catch (IOException ioe)
{
// ignore exception
}
if (fos != null)
try
{
fos.close();
}
catch (IOException ioe)
{
// ignore exception
}
}這個樣板代碼不僅增加了類文件的容量，而且編寫它的單調乏味可能會導致錯誤，甚至可能無法關閉文件。JDK 7引入了“try-with-resource”來克服這個問題。
try-with-resource的基本原理
當執行離開打開和使用資源的范圍時，try-with-resources構造會自動關閉打開的資源，無論是否從該范圍拋出異常。這個構造的語法如下：
try (resource acquisitions)
{
// resource usage
}try關鍵字由分號分隔的資源獲取語句列表參數化，其中每條語句獲取一個資源。每個獲取的資源都可用于try塊的主體，并在執行離開該主體時自動關閉。與常規的try語句不同，try-with-resource不需要catch塊和/或finally塊來跟隨try（），盡管它們可以指定。
考慮以下面向文件的示例：
try (FileInputStream fis = new FileInputStream("abc.txt"))
{
// Do something with fis and the underlying file resource.
}在這個例子中，獲取了底層文件資源（abc.txt）的輸入流。try塊使用這個資源執行某些操作，流（以及文件）在退出try塊時關閉。
將“var”與“try-with-resource”一起使用
JDK 10引入了對var的支持，var是一種具有特殊含義的標識符（即不是關鍵字）。可以使用var和try with資源來減少樣板。例如，可以將前面的示例簡化為以下內容：
try (var fis = new FileInputStream("abc.txt"))
{
// Do something with fis and the underlying file resource.
}在try-with-resource場景中復制文件
本文作者從文件復制應用程序中摘錄了copy（）方法。這種方法的finally塊包含前面介紹的文件關閉樣板。清單8通過使用try-with-resources處理清理，從而改進這種方法。
清單8. Copy.java
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
public class Copy
{
public static void main(String[] args)
{
if (args.length != 2)
{
System.err.println("usage： java Copy srcfile dstfile");
return;
}
try
{
copy(args[0], args[1]);
}
catch (IOException ioe)
{
System.err.println("I/O error： " + ioe.getMessage());
}
}
static void copy(String srcFile, String dstFile) throws IOException
{
try (FileInputStream fis = new FileInputStream(srcFile);
FileOutputStream fos = new FileOutputStream(dstFile))
{
int c;
while ((c = fis.read()) != -1)
fos.write(c);
}
}
}copy（）使用try-with-resources來管理源文件和目標文件資源。下面的圓括號代碼嘗試創建這些文件的文件輸入和輸出流。假設成功，它的主體將執行，將源文件復制到目標文件。
無論是否拋出異常，try-with-resources都能確保在執行離開try塊時關閉這兩個文件。因為不需要前面顯示的樣板文件關閉代碼，所以清單8的copy（）方法要簡單得多，也更容易閱讀。
設計資源類以支持try-with-resources
try-with-resources構造要求資源類實現java.lang.Closeable接口或JDK 7引入的java.lang.AutoCloseable超級接口。Java7之前的類（如Java.io.FileInputStream）實現了Closeable接口，它提供了一個拋出IOException或子類的void close（）方法。
從Java 7開始，類可以實現AutoCloseable，其單個void close（）方法可以拋出Java.lang.Exception或子類。throws子句已經擴展，以適應可能需要添加close（）方法的情況，這些方法可以在IOException層次結構之外拋出異常；例如java.sql.SQLException。
清單9顯示了一個CustomARM應用程序，它展示了如何配置自定義資源類，以便可以在try-with-resources場景中使用它。
清單9. CustomARM.java
public class CustomARM
{
public static void main(String[] args)
{
try (USBPort usbp = new USBPort())
{
System.out.println(usbp.getID());
}
catch (USBException usbe)
{
System.err.println(usbe.getMessage());
}
}
}
class USBPort implements AutoCloseable
{
USBPort() throws USBException
{
if (Math.random() < 0.5)
throw new USBException("unable to open port");
System.out.println("port open");
}
@Override
public void close()
{
System.out.println("port close");
}
String getID()
{
return "some ID";
}
}
class USBException extends Exception
{
USBException(String msg)
{
super(msg);
}
}清單9模擬了一個USB端口，可以打開和關閉該端口，并返回端口的 ID。在構造函數中，使用了 Math.random() 來模擬可能拋出異常的情況，以便可以觀察到 try-with-resources 語句在異常被拋出或未拋出時的行為。
編譯這個清單并運行應用程序。如果端口打開，將看到以下輸出：
port open
some ID
port close如果端口關閉，將看到以下輸出：
unable to open port在try-with-resources中抑制異常
如果你有一定的編程經驗，可能會注意到try-with-resources結構中存在一個潛在的問題：假設try塊拋出了一個異常。這個結構通過調用資源對象的close()方法來關閉資源以做出響應。然而，close()方法本身也可能拋出異常。
當close()方法拋出異常時（例如，FileInputStream的void close()方法可以拋出IOException），這個異常會掩蓋或隱藏原始異常。這看起來像是原始的異常丟失了。
實際上，情況并非如此：try-with-resources會抑制close()拋出的異常。它還通過調用java.lang.Throwable的void addSuppressed(Throwable exception)方法，將異常添加到原始異常的抑制異常數組中。
清單10展示了一個SupExDemo應用程序，它演示了如何在try-with-resources的場景中抑制異常。
清單10. SupExDemo.java
import java.io.Closeable;
import java.io.IOException;
public class SupExDemo implements Closeable
{
@Override
public void close() throws IOException
{
System.out.println("close() invoked");
throw new IOException("I/O error in close()");
}
public void doWork() throws IOException
{
System.out.println("doWork() invoked");
throw new IOException("I/O error in work()");
}
public static void main(String[] args) throws IOException
{
try (SupExDemo supexDemo = new SupExDemo())
{
supexDemo.doWork();
}
catch (IOException ioe)
{
ioe.printStackTrace();
System.out.println();
System.out.println(ioe.getSuppressed()[0]);
}
}
}清單10的doWork（）方法拋出IOException來模擬某種I/O錯誤。close（）方法還會拋出IOException，但這個異常被抑制，這樣它就不會掩蓋doWork（）的異常。
catch塊通過調用Throwable的Throwable[]getSuppressed（）方法來訪問被抑制的異常（從close（）拋出的異常），該方法返回一個包含被抑制異常的數組。由于在這個例子中只有一個異常被抑制，所以只訪問了數組的第一個元素。
編譯清單10并運行應用程序。應該觀察以下輸出：
doWork() invoked
close() invoked
java.io.IOException： I/O error in work()
at SupExDemo.doWork(SupExDemo.java：16)
at SupExDemo.main(SupExDemo.java：23)
Suppressed： java.io.IOException： I/O error in close()
at SupExDemo.close(SupExDemo.java：10)
at SupExDemo.main(SupExDemo.java：24)
java.io.IOException： I/O error in close()多重捕獲塊(multi-catch)
從JDK 7開始，可以在單個catch塊中捕獲多種類型的異常。這種多重捕獲特性的目的是減少代碼重復，并減少捕獲過于寬泛的異常(例如，catch (Exception e))的誘惑。
假設開發了一個應用程序，可以靈活地將數據復制到數據庫或文件中。清單11展示了一個CopyToDatabaseOrFile類，該類模擬了這種情況，并演示了catch塊代碼重復的問題。
清單11.CopyToDatabaseOrFile.java
import java.io.IOException;
import java.sql.SQLException;
public class CopyToDatabaseOrFile
{
public static void main(String[] args)
{
try
{
copy();
}
catch (IOException ioe)
{
System.out.println(ioe.getMessage());
// additional handler code
}
catch (SQLException sqle)
{
System.out.println(sqle.getMessage());
// additional handler code that's identical to the previous handler's
// code
}
}
static void copy() throws IOException, SQLException
{
if (Math.random() < 0.5)
throw new IOException("cannot copy to file");
else
throw new SQLException("cannot copy to database");
}
}JDK 7通過允許在catch塊中指定多個異常類型來克服代碼重復問題，其中每個連續的類型都通過在這些類型之間放置豎線（|）與其前一個類型分開：
try
{
copy();
}
catch (IOException | SQLException iosqle)
{
System.out.println(iosqle.getMessage());
}現在，當copy()拋出異常時，異常將被捕獲并由catch塊處理。
當在catch塊的頭文件中列出多個異常類型時，該參數被隱式地視為final。因此，不能更改參數的值。例如，不能更改存儲在前一個代碼片段的iosqle參數中的引用。
縮減字節碼
編譯處理多種異常類型的catch塊所產生的字節碼將比編譯每個只處理列出的一種異常類型的幾個catch塊要小。處理多種異常類型的catch塊在編譯期間不會產生重復的字節碼。換句話說，字節碼不包含復制的異常處理程序。
最終重新拋出異常
從JDK 7開始，Java編譯器能夠比之前的Java版本更精確地分析被重拋的異常。這個特性僅在沒有對被重拋的異常的catch塊參數進行賦值時有效，該參數被認為是有效的final。當前面的try塊拋出一個屬于參數類型的超類型/子類型的異常時，編譯器會拋出捕獲的異常的實際類型，而不是拋出參數的類型(就像以前的Java版本那樣)。
這個最終重拋異常特性的目的是為了方便在代碼塊周圍添加try-catch語句來攔截、處理并重拋異常，同時不影響從代碼中靜態確定的異常集。此外，這個特性允許在異常被拋出的地方附近提供一個通用的異常處理器來部分處理異常，并在其他地方提供更精確的處理程序來處理重拋的異常。考慮清單12。
清單12.MonitorEngine.java
class PressureException extends Exception
{
PressureException(String msg)
{
super(msg);
}
}
class TemperatureException extends Exception
{
TemperatureException(String msg)
{
super(msg);
}
}
public class MonitorEngine
{
public static void main(String[] args)
{
try
{
monitor();
}
catch (Exception e)
{
if (e instanceof PressureException)
System.out.println("correcting pressure problem");
else
System.out.println("correcting temperature problem");
}
}
static void monitor() throws Exception
{
try
{
if (Math.random() < 0.1)
throw new PressureException("pressure too high");
else
if (Math.random() > 0.9)
throw new TemperatureException("temperature too high");
else
System.out.println("all is well");
}
catch (Exception e)
{
System.out.println(e.getMessage());
throw e;
}
}
}清單12模擬了一個實驗性火箭發動機的測試，以檢查發動機的壓力或溫度是否超過了安全閾值。它通過monitor()助手方法執行這個測試。
monitor()方法的try塊在檢測到極端壓力時拋出PressureException，在檢測到極端溫度時拋出TemperatureException。（由于這只是一個模擬，因此使用了隨機數——java.lang.Math類的靜態double random()方法返回一個介于0.0和（接近）1.0之間的隨機數。）try塊后面跟著一個catch塊，這個catch塊的目的是通過輸出警告消息來部分處理異常。然后重新拋出此異常，以便monitor()的調用方法可以完成對異常的處理。
在JDK 7之前，不能在monitor()的throws子句中指定PressureException和TemperatureException，因為catch塊的e參數是java.lang.Exception類型，并且重新拋出異常被視為拋出參數的類型。JDK 7及后續JDK允許在throws子句中指定這些異常類型，因為它們的編譯器可以確定通過throw e拋出的異常來自try塊，并且只能從該塊拋出PressureException和TemperatureException。
因為現在可以指定靜態void monitor()拋出PressureException, TemperatureException，可以在調用monitor()時提供更精確的處理程序，如下面的代碼片段所示：
try
{
monitor();
}
catch (PressureException pe)
{
System.out.println("correcting pressure problem");
}
catch (TemperatureException te)
{
System.out.println("correcting temperature problem");
}由于JDK 7中的最終重新拋出提供了改進的類型檢查，因此在以前版本的Java下編譯的源代碼可能無法在以后的JDK下編譯。例如，考慮清單13。
清單13.BreakageDemo.java
class SuperException extends Exception
{
}
class SubException1 extends SuperException
{
}
class SubException2 extends SuperException
{
}
public class BreakageDemo
{
public static void main(String[] args) throws SuperException
{
try
{
throw new SubException1();
}
catch (SuperException se)
{
try
{
throw se;
}
catch (SubException2 se2)
{
}
}
}
}清單13可以在JDK 6和更早版本下編譯。但是，它無法在后續版本的 JDK中編譯，因為這些JDK的編譯器會檢測并報告這樣一個事實，即在相應的try語句體中從未拋出subeexception2。這是一個小問題，可能很少會在你的程序中遇到，讓編譯器檢測冗余代碼源是值得的。移除這些冗余代碼可以使代碼更加清晰，并且生成的類文件更小。
StackWalker和StackWalking API
通過Thread或Throwable的getStackTrace()方法獲取堆棧跟蹤代價高昂，并且會影響性能。JVM急切地捕獲整個堆棧的快照(隱藏的堆棧幀除外)，即使只需要前幾個幀。此外，其代碼可能必須處理不感興趣的幀，這也很耗時。最后，無法訪問由堆棧幀表示的方法所聲明的類的實際 java.lang.Class 實例。為訪問這個Class對象，必須擴展java.lang.SecurityManager以訪問受保護的getClassContext()方法，該方法返回當前執行堆棧作為 Class 對象的數組。
JDK 9引入了java.lang.StackWalker類(及其嵌套的Option類和StackFrame接口)，作為StackTraceElement(加上SecurityManager)的一個性能更高、功能更強的替代方案。
總結
本文完成了對Java異常處理幀的兩部分介紹。可能需要通過回顧Java教程中的Oracle異常課程來加強對這個幀的理解。另一個很好的資源是Baeldung的Java異常處理教程，其中包括異常處理中的反模式。
原文標題：Exceptions in Java： Advanced features and types，作者：Jeff Friesen
