企業應用程序在構建時常常對異常處理關注甚少，這會造成對低級異常（如 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）很容易（有時也很誘人），但如果一開始就建立一個可靠的、深思熟慮的異常模型，則您將在應用程序上少花很多精力。創建一個嵌套的、層次結構化的異常框架將改進代碼的可讀性及其可用性。


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