企業(yè)應(yīng)用程序在構(gòu)建時(shí)經(jīng)常對(duì)異常處理關(guān)注甚少，這會(huì)造成對(duì)低級(jí)異常（如 java.rmi.RemoteException 和 javax.naming.NamingException）的過度依靠。在 EJB 最佳實(shí)踐的這篇專欄文章中，Brett McLaughlin 解釋了為什么對(duì)異常處理投入一點(diǎn)關(guān)注就會(huì)給我們帶來很大的幫助，并向您展示了兩種簡單技術(shù)，它們將幫助您正確地構(gòu)建更健壯且有用的異常處理框架。
在本系列先前的技巧文章中，異常處理不屬于討論的核心范圍之內(nèi)。但是，您可能會(huì)發(fā)現(xiàn)一點(diǎn)，那就是我們一直都回避來自 Web 層的低級(jí)異常。我們向客戶機(jī)提供諸如 applicationException 和 InvalidDataException 之類的異常，而沒有讓 Web 層處理象 java.rmi.RemoteException 或 javax.naming.NamingException 這樣的異常。

遠(yuǎn)程和命名異常是系統(tǒng)級(jí)異常，而應(yīng)用程序和非法數(shù)據(jù)異常是業(yè)務(wù)級(jí)異常，因?yàn)樗鼈兲峤桓m用的業(yè)務(wù)信息。當(dāng)決定拋出何種類型的異常時(shí)，您應(yīng)該總是首先考慮將要處理所報(bào)告異常的層。Web 層通常是由執(zhí)行業(yè)務(wù)任務(wù)的最終用戶驅(qū)動(dòng)的，所以最好用它處理業(yè)務(wù)級(jí)異常。但是，在 EJB 層，您正在執(zhí)行系統(tǒng)級(jí)任務(wù)，如使用 JNDI 或數(shù)據(jù)庫。盡管這些任務(wù)最終將被合并到業(yè)務(wù)邏輯中，但是最好用諸如 RemoteException 之類的系統(tǒng)級(jí)異常來表示它們。

理論上，您可以讓所有 Web 層方法預(yù)期處理和響應(yīng)單個(gè)應(yīng)用程序異常，正如我們?cè)谙惹暗囊恍┦纠兴龅囊粯印５@種方法不適用于長時(shí)間運(yùn)行。讓您的委派方法拋出更具體的異常，這是一個(gè)好得多的異常處理方案，從根本上講，這對(duì)接收客戶機(jī)更有用。在這篇技巧文章中，我們將討論兩種技術(shù)，它們將有助于您創(chuàng)建信息更豐富、更具體的異常，而不會(huì)生成大量不必要的代碼。

嵌套的異常
在設(shè)計(jì)可靠的異常處理方案時(shí)，要考慮的第一件事情就是對(duì)所謂的低級(jí)或系統(tǒng)級(jí)異常進(jìn)行抽象化。這些核心 Java 異常通常會(huì)報(bào)告網(wǎng)絡(luò)流量中的錯(cuò)誤、JNDI 或 RMI 問題，或者是應(yīng)用程序中的其它技術(shù)問題。RemoteException、EJBException 和 NamingException 是企業(yè) Java 編程中低級(jí)異常的常見例子。

這些異常完全沒有任何意義，由 Web 層的客戶機(jī)接收時(shí)尤其輕易混淆。假如客戶機(jī)調(diào)用 purchase() 并接收到 NamingException，那么它在解決這個(gè)異常時(shí)會(huì)一籌莫展。同時(shí)，應(yīng)用程序代碼可能需要訪問這些異常中的信息，因此不能輕易地拋棄或忽略它們。

答案是提供一類更有用的異常，它還包含低級(jí)異常。清單 1 演示了一個(gè)專為這一點(diǎn)設(shè)計(jì)的簡單 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 中的代碼很簡單；我們已經(jīng)簡單地將多個(gè)異常“串”在一起，以創(chuàng)建單個(gè)、嵌套的異常。但是，真正的好處在于將這種技術(shù)作為出發(fā)點(diǎn)，以創(chuàng)建特定于應(yīng)用程序的異常層次結(jié)構(gòu)。異常層次結(jié)構(gòu)將答應(yīng) EJB 客戶機(jī)既接收特定于業(yè)務(wù)的異常也接收特定于系統(tǒng)的信息，而不需要編寫大量額外代碼。

異常層次結(jié)構(gòu)
異常層次結(jié)構(gòu)應(yīng)該從一些十分健壯而又通用的異常入手，如 ApplicationException。假如您將頂級(jí)異常搞得太具體，那么其結(jié)果是您今后將不得不重新構(gòu)造層次結(jié)構(gòu)，以適應(yīng)某些較通用的情況。

因此，讓我們假定您的應(yīng)用程序要求 NoSuchBookException、InsufficientFundsException 和 SystemUnavailableException。您不必創(chuàng)建這三個(gè)異常，讓它們繼續(xù) ApplicationException，然后只需提供極少幾個(gè)必須的構(gòu)造器來創(chuàng)建格式化的消息。清單 2 是此類異常層次結(jié)構(gòu)的示例：

清單 2. 異常層次結(jié)構(gòu) 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.");
}
}

當(dāng)需要編寫大量專用異常時(shí)，異常層次結(jié)構(gòu)極大地簡化了工作。對(duì)于一個(gè)異常，為每個(gè)異常類添加一個(gè)或兩個(gè)構(gòu)造器，所花費(fèi)時(shí)間很少不超過幾分鐘。您還經(jīng)常需要給這些更具體的異常（這些異常也是主應(yīng)用程序異常的子類）提供子類，以提供更具體的異常。例如，您可能需要 InvalidTitleException 和 BackorderedException 來繼續(xù) NoSuchBookException。
企業(yè)應(yīng)用程序在構(gòu)建時(shí)通常都不會(huì)注重異常處理。盡管依靠低級(jí)異常（如 RemoteException 和 NamingException）很輕易（有時(shí)也很誘人），但假如一開始就建立一個(gè)可靠的、深思熟慮的異常模型，則您將在應(yīng)用程序上少花很多精力。創(chuàng)建一個(gè)嵌套的、層次結(jié)構(gòu)化的異常框架將改進(jìn)代碼的可讀性及其可用性。