企業(yè)應(yīng)用程序在構(gòu)建時常常對異常處理關(guān)注甚少，這會造成對低級異常（如 java.rmi.RemoteException 和 javax.naming.NamingException）的過度依賴。在 EJB 最佳實踐的這篇專欄文章中，Brett McLaughlin 解釋了為什么對異常處理投入一點關(guān)注就會給我們帶來很大的幫助，并向您展示了兩種簡單技術(shù)，它們將幫助您正確地構(gòu)建更健壯且有用的異常處理框架。

在本系列先前的技巧文章中，異常處理不屬于討論的核心范圍之內(nèi)。但是，您可能會發(fā)現(xiàn)一點，那就是我們一直都回避來自 Web 層的低級異常。我們向客戶機提供諸如 ApplicationException 和 InvalidDataException 之類的異常，而沒有讓 Web 層處理象 java.rmi.RemoteException 或 javax.naming.NamingException 這樣的異常。

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

理論上，您可以讓所有 Web 層方法預(yù)期處理和響應(yīng)單個應(yīng)用程序異常，正如我們在先前的一些示例中所做的一樣。但這種方法不適用于長時間運行。讓您的委派方法拋出更具體的異常，這是一個好得多的異常處理方案，從根本上講，這對接收客戶機更有用。在這篇技巧文章中，我們將討論兩種技術(shù)，它們將有助于您創(chuàng)建信息更豐富、更具體的異常，而不會生成大量不必要的代碼。

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

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

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

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

因此，讓我們假定您的應(yīng)用程序要求 NoSuchBookException、InsufficientFundsException 和 SystemUnavailableException。您不必創(chuàng)建這三個異常，讓它們繼承 ApplicationException，然后只需提供極少幾個必須的構(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)需要編寫大量專用異常時，異常層次結(jié)構(gòu)極大地簡化了工作。對于一個異常，為每個異常類添加一個或兩個構(gòu)造器，所花費時間很少不超過幾分鐘。您還經(jīng)常需要給這些更具體的異常（這些異常也是主應(yīng)用程序異常的子類）提供子類，以提供更具體的異常。例如，您可能需要 InvalidTitleException 和 BackorderedException 來繼承 NoSuchBookException。

企業(yè)應(yīng)用程序在構(gòu)建時通常都不會注意異常處理。盡管依靠低級異常（如 RemoteException 和 NamingException）很容易（有時也很誘人），但如果一開始就建立一個可靠的、深思熟慮的異常模型，則您將在應(yīng)用程序上少花很多精力。創(chuàng)建一個嵌套的、層次結(jié)構(gòu)化的異常框架將改進代碼的可讀性及其可用性。


關(guān)于作者
Brett McLaughlin 從 Logo 時代（還記得那個小三角嗎？）就開始從事計算機工作了。他現(xiàn)在專門研究用 Java 和 Java 相關(guān)技術(shù)構(gòu)建應(yīng)用程序基礎(chǔ)結(jié)構(gòu)。過去幾年他一直在 Nextel Communications 和 Allegiance Telecom, Inc. 致力于實現(xiàn)這些基礎(chǔ)結(jié)構(gòu)。Brett 是 Java Apache 項目 Turbine 的共同創(chuàng)始人之一，該項目為使用 Java servlet 的 Web 應(yīng)用程序開發(fā)構(gòu)建可重用的組件體系結(jié)構(gòu)。他還是 EJBoss 項目（一個開放源碼 EJB 應(yīng)用程序服務(wù)器）和 Cocoon（一個開放源碼 XML Web 發(fā)布引擎）的志愿開發(fā)人員之一。可通過 brett@oreilly.com 與 Brett 聯(lián)系。