在本系列先前的技巧文章中，異常處理不屬於討論的核心範圍之內。但是，您可能會發現一點，那就是我們一直都回避來自 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. 嵌套的異常
|
清單 1 中的代碼很簡單；我們已經簡單地將多個異常“串”在一起，以創建單個、嵌套的異常。但是，真正的好處在於將這種技術作爲出發點，以創建特定於應用程序的異常層次結構。異常層次結構將允許 EJB 客戶機既接收特定於業務的異常也接收特定於系統的信息，而不需要編寫大量額外代碼。
  |
|
異常層次結構應該從一些十分健壯而又通用的異常入手，如 ApplicationException 。如果您將頂級異常搞得太具體，那麼其結果是您今後將不得不重新構造層次結構，以適應某些較通用的情況。
因此，讓我們假定您的應用程序要求 NoSuchBookException 、 InsufficientFundsException 和 SystemUnavailableException 。您不必創建這三個異常，讓它們繼承 ApplicationException ，然後只需提供極少幾個必須的構造器來創建格式化的消息。清單 2 是此類異常層次結構的示例：
清單 2. 異常層次結構
|
當需要編寫大量專用異常時，異常層次結構極大地簡化了工作。對於一個異常，爲每個異常類添加一個或兩個構造器，所花費時間很少不超過幾分鐘。您還經常需要給這些更具體的異常（這些異常也是主應用程序異常的子類）提供子類，以提供更具體的異常。例如，您可能需要 InvalidTitleException 和 BackorderedException 來繼承 NoSuchBookException 。
企業應用程序在構建時通常都不會注意異常處理。儘管依靠低級異常（如 RemoteException 和 NamingException ）很容易（有時也很誘人），但如果一開始就建立一個可靠的、深思熟慮的異常模型，則您將在應用程序上少花很多精力。創建一個嵌套的、層次結構化的異常框架將改進代碼的可讀性及其可用性。