企業應用程序在構建時常常對異常處理關注甚少，這會造成對低級異常（如 java.rmi.RemoteException 和 javax.naming.NamingException）的過度依賴。我們向客戶機提供諸如 ApplicationException 和 InvalidDataException 之類的異常，而沒有讓 Web 層處理象 java.rmi.RemoteException 或 javax.naming.NamingException 這樣的異常。

　　遠程和命名異常是系統級異常，而應用程序和非法數據異常是業務級異常，因為它們提交更適用的業務信息。當決定拋出何種類型的異常時，您應該總是首先考慮將要處理所報告異常的層。

　　Web 層通常是由執行業務任務的最終用戶驅動的，所以最好用它處理業務級異常。但是，在 EJB 層，您正在執行系統級任務，如使用 JNDI 或數據庫。盡管這些任務最終將被合并到業務邏輯中，但是最好用諸如 RemoteException 之類的系統級異常來表示它們。 mda.com

　　理論上，您可以讓所有 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 客戶機既接收特定于業務的異常也接收特定于系統的信息，而不需要編寫大量額外代碼。

轉帖于：軟件水平考試_考試吧