<？xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
企業應用程序在構建時經常對異常處理關注甚少，這會造成對低級異常（如 java.rmi.RemoteException 和 javax.naming.NamingException）的過度依靠。在 EJB 最佳實踐的這篇專欄文章中，Brett McLaughlin 解釋了為什麼對異常處理投入一點關注就會給我們帶來很大的幫助，並向您展示了兩種簡單技術，它們將幫助您正確地構建更健壯且有用的異常處理框架。
在本系列先前的技巧文章中，異常處理不屬於討論的核心范圍之內。但是，您可能會發現一點，那就是我們一直都回避來自 Web 層的低級異常。我們向客戶機提供諸如 ApplicationException 和 InvalidDataException 之類的異常，而沒有讓 Web 層處理象 java.rmi.RemoteException 或 javax.naming.NamingException 這樣的異常。
遠程和命名異常是系統級異常，而應用程序和非法數據異常是業務級異常，因為它們提交更適用的業務信息。當決定拋出何種類型的異常時，您應該總是首先考慮將要處理所報告異常的層。Web 層通常是由執行業務任務的最終用戶驅動的，所以最好用它處理業務級異常。但是，在 EJB 層，您正在執行系統級任務，如使用 JNDI 或數據庫。盡管這些任務最終將被合並到業務邏輯中，但是最好用諸如 RemoteException 之類的系統級異常來表示它們。
理論上，您可以讓所有 Web 層方法預期處理和響應單個應用程序異常，正如我們在先前的一些示例中所做的一樣。但這種方法不適用於長時間運行。讓您的委派方法拋出更具體的異常，這是一個好得多的異常處理方案，從根本上講，這對接收客戶機更有用。在這篇技巧文章中，我們將討論兩種技術，它們將有助於您創建信息更豐富、更具體的異常，而不會生成大量不必要的代碼。
嵌套的異常
在設計可靠的異常處理方案時，要考慮的第一件事情就是對所謂的低級或系統級異常進行抽象化。這些核心 Java 異常通常會報告網絡流量中的錯誤、JNDI 或 RMI 問題，或者是應用程序中的其它技術問題。RemoteException、EJBException 和 NamingException 是企業 Java 編程中低級異常的常見例子。
這些異常完全沒有任何意義，由 Web 層的客戶機接收時尤其輕易混淆。假如客戶機調用 purchase() 並接收到 NamingException，那麼它在解決這個異常時會一籌莫展。同時，應用程序代碼可能需要訪問這些異常中的信息，因此不能輕易地拋棄或忽略它們。
答案是提供一類更有用的異常，它還包含低級異常。清單 1 演示了一個專為這一點設計的簡單 ApplicationException：
清單 1. 嵌套的異常 package com.ibm;
import java.io.PrintStream;
import java.io.PrintWriter;
public class ApplicationException extends Exception {
/** A wrapped Throwable */
protected Throwable cause;
public ApplicationException() {
super("Error occurred in application.");
}
public ApplicationException(String message) {
super(message);
}
public ApplicationException(String message, Throwable cause) {
super(message);
this.cause = cause;
}
// Created to match the JDK 1.4 Throwable method.
public Throwable initCause(Throwable cause) {
this.cause = cause;
return cause;
}
public String getMessage() {
// Get this exception's message.
String msg = super.getMessage();
Throwable parent = this;
Throwable child;
// Look for nested exceptions.
while((child = getNestedException(parent)) != null) {
// Get the child's message.
String msg2 = child.getMessage();
// If we found a message for the child exception,
// we append it.
if (msg2 != null) {
if (msg != null) {
msg += ": " + msg2;
} else {
msg = msg2;
}
}
// Any nested ApplicationException will append its own
// children, so we need to break out of here.
if (child instanceof ApplicationException) {
break;
}
parent = child;
}
// Return the completed message.
return msg;
}
public void printStackTrace() {
// Print the stack trace for this exception.
super.printStackTrace();
Throwable parent = this;
Throwable child;
// Print the stack trace for each nested exception.
while((child = getNestedException(parent)) != null) {
if (child != null) {
System.err.print("Caused by: ");
child.printStackTrace();
if (child instanceof ApplicationException) {
break;
}
parent = child;
}
}
}
public void printStackTrace(PrintStream s) {
// Print the stack trace for this exception.
super.printStackTrace(s);
Throwable parent = this;
Throwable child;
// Print the stack trace for each nested exception.
while((child = getNestedException(parent)) != null) {
if (child != null) {
s.print("Caused by: ");
child.printStackTrace(s);
if (child instanceof ApplicationException) {
break;
}
parent = child;
}
}
}
public void printStackTrace(PrintWriter w) {
// Print the stack trace for this exception.
super.printStackTrace(w);
Throwable parent = this;
Throwable child;
// Print the stack trace for each nested exception.
while((child = getNestedException(parent)) != null) {
if (child != null) {
w.print("Caused by: ");
child.printStackTrace(w);
if (child instanceof ApplicationException) {
break;
}
parent = child;
}
}
}
public Throwable getCause() {
return cause;
}
}
清單 1 中的代碼很簡單；我們已經簡單地將多個異常“串”在一起，以創建單個、嵌套的異常。但是，真正的好處在於將這種技術作為出發點，以創建特定於應用程序的異常層次結構。異常層次結構將答應 EJB 客戶機既接收特定於業務的異常也接收特定於系統的信息，而不需要編寫大量額外代碼。
異常層次結構
異常層次結構應該從一些十分健壯而又通用的異常入手，如 ApplicationException。假如您將頂級異常搞得太具體，那麼其結果是您今後將不得不重新構造層次結構，以適應某些較通用的情況。
因此，讓我們假定您的應用程序要求 NoSuchBookException、InsufficientFundsException 和 SystemUnavailableException。您不必創建這三個異常，讓它們繼續 ApplicationException，然後只需提供極少幾個必須的構造器來創建格式化的消息。清單 2 是此類異常層次結構的示例：
清單 2. 異常層次結構 package com.ibm.library;
import com.ibm.ApplicationException;
public class NoSuchBookException extends ApplicationException {
public NoSuchBookException(String bookName, String libraryName) {
super("The book '" + bookName + "' was not found in the '" +
libraryName + "' library.");
}
}
當需要編寫大量專用異常時，異常層次結構極大地簡化了工作。對於一個異常，為每個異常類添加一個或兩個構造器，所花費時間很少不超過幾分鐘。您還經常需要給這些更具體的異常（這些異常也是主應用程序異常的子類）提供子類，以提供更具體的異常。例如，您可能需要 InvalidTitleException 和 BackorderedException 來繼續 NoSuchBookException。
企業應用程序在構建時通常都不會注重異常處理。盡管依靠低級異常（如 RemoteException 和 NamingException）很輕易（有時也很誘人），但假如一開始就建立一個可靠的、深思熟慮的異常模型，則您將在應用程序上少花很多精力。創建一個嵌套的、層次結構化的異常框架將改進代碼的可讀性及其可用性。
