Srikanth Shenoy(srikanth@srikanth.org)
J2EE 顧問
2002 年 5 月
隨著 J2EE 成為企業開發平臺之選,越來越多基于 J2EE 的應用程序將投入生產。J2EE 平臺的重要組件之一是 EnterPRise javaBean(EJB)API。J2EE 和 EJB 技術一起提供了許多優點,但隨之而來的還有一些新的挑戰。非凡是企業系統,其中的任何問題都必須快速得到解決。在本文中,企業 Java 編程老手 Srikanth Shenoy 展現了他在 EJB 異常處理方面的最佳做法,這些做法可以更快解決問題。
在 hello-world 情形中,異常處理非常簡單。每當碰到某個方法的異常時,就捕捉該異常并打印堆棧跟蹤或者聲明這個方法拋出異常。不幸的是,這種辦法不足以處理現實中出現的各種類型的異常。在生產系統中,當有異常拋出時,很可能是最終用戶無法處理他或她的請求。當發生這樣的異常時,最終用戶通常希望能這樣:
理想情況下,企業級系統將不僅為客戶提供這些基本的服務,還將預備好一些必要的后端機制。舉例來說,客戶服務小組應該收到即時的錯誤通知,以便在客戶打電話求助之前服務代表就能意識到問題。此外,服務代表應該能夠交叉引用用戶的唯一錯誤號和產品日志,從而快速識別問題 — 最好是能把問題定位到確切的行號或確切的方法。為了給最終用戶和支持小組提供他們需要的工具和服務,在構建一個系統時,您就必須對系統被部署后可能出問題的所有地方心中有數。
在本文中,我們將談談基于 EJB 的系統中的異常處理。我們將從回顧異常處理的基礎知識開始,包括日志實用程序的使用,然后,很快就轉入對 EJB 技術如何定義和治理不同類型的異常進行更具體的討論。此后,我們將通過一些代碼示例來研究一些常見的異常處理解決方案的優缺點,我還將展示我自己在充分利用 EJB 異常處理方面的最佳做法。
請注重,本文假設您熟悉 J2EE 和 EJB 技術。您應理解實體 bean 和會話 bean 的差異。假如您對 bean 治理的持久性(bean-managed persistence(BMP))和容器治理的持久性(container-managed persistence(CMP))在實體 bean 上下文中是什么意思稍有了解,也是有幫助的。請參閱參考資料部分了解關于 J2EE 和 EJB 技術的更多信息。
異常處理基礎知識
解決系統錯誤的第一步是建立一個與生產系統具有相同構造的測試系統,然后跟蹤導致拋出異常的所有代碼,以及代碼中的所有不同分支。在分布式應用程序中,很可能是調試器不工作了,所以,您可能將用 System.out.println()
方法跟蹤異常。System.out.println
盡管很方便,但開銷巨大。在磁盤 I/O 期間,System.out.println
對 I/O 處理進行同步,這極大降低了吞吐量。在缺省情況下,堆棧跟蹤被記錄到控制臺。但是,在生產系統中,瀏覽控制臺以查看異常跟蹤是行不通的。而且,不能保證堆棧跟蹤會顯示在生產系統中,因為,在 NT 上,系統治理員可以把 System.out
和 System.err
映射到 ' '
,在 UNIX 上,可以映射到 dev/null
。此外,假如您把 J2EE 應用程序服務器作為 NT 服務運行,甚至不會有控制臺。即使您把控制臺日志重定向到一個輸出文件,當產品 J2EE 應用程序服務器重新啟動時,這個文件很可能也將被重寫。
第 1 點顯然與第 3 點相抵觸。實際的解決方案是以下兩者的折衷:您在距異常被拋出多近的地方將它捕捉;在完全丟失原始異常的意圖或內容之前,您可以讓異常落在多遠的地方。
注:盡管這些原則的應用遍及所有 EJB 異常處理機制,但它們并不是非凡針對 EJB 異常處理的。
由于以上這些原因,把代碼組裝成產品并同時包含 System.out.println
并不是一種選擇。在測試期間使用 System.out.println
,然后在形成產品之前除去 System.out.println
也不是上策,因為這樣做意味著您的產品代碼與測試代碼運行得不盡相同。您需要的是一種聲明控制日志機制,以使您的測試代碼和產品代碼相同,并且當記錄日志以聲明方式關閉時,給產品帶來的性能開銷最小。
這里的解決方案顯然是使用一個日志實用程序。采用恰當的編碼約定,日志實用程序將負責精確地記錄下任何類型的消息,不論是系統錯誤還是一些警告。所以,我們將在進一步講述之前談談日志實用程序。
日志領域:鳥瞰
每個大型應用程序在開發、測試及產品周期中都使用日志實用程序。在今天的日志領域中,有幾個角逐者,其中有兩個廣為人知。一個是 Log4J,它是來自 Apache 的 Jakarta 的一個開放源代碼的項目。另一個是 J2SE 1.4 捆綁提供的,它是最近剛加入到這個行列的。我們將使用 Log4J 說明本文所討論的最佳做法;但是,這些最佳做法并不非凡依靠于 Log4J。
Log4J 有三個主要組件:layout、appender 和 category。Layou 代表消息被記錄到日志中的格式。appender 是消息將被記錄到的物理位置的別名。而 category 則是有名稱的實體:您可以把它當作是日志的句柄。layout 和 appender 在 xml 配置文件中聲明。每個 category 帶有它自己的 layout 和 appender 定義。當您獲取了一個 category 并把消息記錄到它那里時,消息在與該 category 相關聯的各個 appender 處結束,并且所有這些消息都將以 XML 配置文件中指定的 layout 格式表示。
Log4J 給消息指定四種優先級:它們是 ERROR、WARN、INFO 和 DEBUG。為便于本文的討論,所有異常都以具有 ERROR 優先級記錄。當記錄本文中的一個異常時,我們將能夠找到獲取 category(使用 Category.getInstance(String name)
方法)的代碼,然后調用方法 category.error()
(它與具有 ERROR 優先級的消息相對應)。
盡管日志實用程序能幫助我們把消息記錄到適當的持久位置,但它們并不能根除問題。它們不能從產品日志中精確找出某個客戶的問題報告;這一便利技術留給您把它構建到您正在開發的系統中。
要了解關于 Log4J 日志實用程序或 J2SE 所帶的日志實用程序的更多信息,請參閱參考資料部分。
異常的類別
新聞熱點
疑難解答