J2EE中的異常管理及錯誤跟蹤框架一(圖)

2019-11-18 12:27:01

字體：大中小

來源：轉載

供稿：網友

　　摘要
　　
　　回顧一下你上一個J2EE工程，是否碰到過類似錯誤沒有記入日志或者被多次記錄的情況？是否只是因為在某處代碼吃掉了異常導致你花費無數次時間來跟蹤一個bug?是否你的用戶直接看到了堆棧的跟蹤信息？假如這樣的話，你可能需要一種通用的異常治理的策略和一些補充的代碼。這篇文章為你提供了在J2EE項目中通過使用錯誤處理框架使用一些策略的基礎。(3100個英文單詞，2005年7月11日)
　　
　　java中關于異常處理的爭論可以被認為是一種信仰上的爭執：一方面，強制異常(checked exceptions)的支持者認為調用者應該處理他們調用代碼出現的異常；另一方面，非強制(unchecked exceptions)異常的追隨者認為強制異常混亂了代碼，而且通?？蛻舳瞬荒芰⒓刺幚?，那為什么還要檢查他呢。
　　
　　作為初級工程師，我們首先信仰的是強制異常，但幾年后，在使用N久的try/catch/finally后，我們開始轉向非強制異常了。因為我們開始相信一些處理錯誤狀況的基本規則：
　　
　　假如需要處理異常，那么就處理
　　
　　假如處理不了，就拋出
　　
　　假如拋不了，就用非強制的基類異常包裝后再拋出
　　
　　但這些異常被拋到最頂層時會怎么樣呢？對這種情況，我們有一個底線確保錯誤信息被記錄并且用戶得到正確的提示。
　　
　　本文提供了另外一種框架來處理異常，它擴展了“Create an application-Wide User session for J2EE”(JavaWorld, 2005年3月)所提出的企業應用session工具。使用此框架的J2EE應用將：
　　
　　總是向用戶提供有意義的錯誤信息
　　
　　記下未處理的錯誤環境，并且只記錄一次
　　
　　在日志文件中用唯一的請求ID號對異常進行編號，以便進行高精度的調試
　　
　　在各層中設置一個強壯的、可擴展的，而又簡單的策略來處理異常
　　
　　為了搭建框架，我們運用了面向狀態編程(AOP，aspect-oriented PRogramming)、設計模式和使用XDoclet進行代碼生成。
　　
　　你可以在資源中找到所有代碼及一個使用框架的J2EE應用。這些源程序組成了一個名為Rampart的完整框架，當初是為丹麥哥本哈根基于J2EE的電子保健系統應用(EHR, electronic healthcare records)而開發的。
　　
　　為什么我們需要通用的錯誤處理方法
　　
　　在項目的開始，我們會做一些要害性的系統架構決定，如：系統中的元素如何交互？會話狀態保存在哪兒？哪種通信協議會被使用等等。但這里并沒有包含錯誤處理。因而每個開發人員都可以任意決定如何定義、分類、建模和處理錯誤。作為一個開發人員，你可以想象在這種方式下的結果：
　　
　　1. 臃腫的日志：每個try/catch都包含log語句，這導致被污染的代碼生成臃腫和多余的日志入口。
　　
　　2. 多余的實現：同一類型的錯誤有不同的表示，這導致處理的復雜化。
　　
　　3. 破碎的封裝：來自其他組件的異常被定義為方法標識的一部分，這導致接口和實現的分離被打破了。
　　
　　4. 不明確的異常定義：方法簽名通常采用拋出java.lang.Exception，這導致客戶端不能明確得到方法錯誤的語義。
　　
　　通常沒有定義異常處理策略的借口是：java已經提供了異常處理。這是事實，java也提供一貫的定義、通信、傳播及響應異常的工具。但開發人員需要決定如何在實際的項目中使用這些服務。幾個方面是必須要考慮的，如：
　　
　　1. 檢查或不檢查異常：是否應該檢查或不檢查新異常類？
　　
　　2. 異常的使用者：究竟是誰需要知道什么時候會發生未處理的異常及由誰來負責記錄及通知操作人員？
　　
　　3. 基礎的異常層次：異常需要包含什么信息及異常層次需要反映什么語義？
　　
　　4. 傳遞；是否未處理的異常會被定義或傳遞給別的異常類，及他們如何在分布式環境中傳遞？
　　
　　5. 解釋：未處理的異常如何被解釋為可閱讀的，甚至支持多語言的信息？
　　
　　在框架中封裝規則，要快！
　　
　　我們給出的通用異常處理策略是基于如下的因素：
　　
　　使用非強制的異常：使用強制異常，調用者要被迫處理他們幾乎不能處理的錯誤。非強制的異常則給調用者一個選擇。在使用第三方類庫時，你不能控制異常是強制或非強制的。這種情況下，你需要用非強制異常來包含強制異常。在使用非強制異常時，最大的讓步是你不能再強制調用者來處理異常了。然而作為接口定義的一部分，異常仍是約定的要害部分并且繼續成為Javadoc文檔的一部分。
　　
　　封裝異常處理并在每一層的頂層提供處理器：你可以專注于只處理業務邏輯相關的異常。處理器可以為特定層剩余的異常執行標準操作：記錄日志、系統治理提示及轉換等等。
　　
　　通過“簡單生活”方式來建模異常類層次：不要在發現新的錯誤類型時就創建新的異常類。首先問一下是否可以作為其他類型的變體來對待或者調用者確實需要捕捉。記住異常至少在某方面是可以用他的屬性來為不同的狀況建立變化模型的對象。較少的異常類在開始時是足夠的，但也僅在這種情況下可能需要用特定屬性來處理。
　　
　　提供有意義的信息給使用者：未處理的異常代表不可預知的事件和問題。告訴用戶并且保存細節給技術支持人員。
　　
　　雖然在不同的項目中需求、限制、異常層次及通知機制會有所不同，但許多元素還是一致的。因此為什么不完全地通過框架實現通用的策略呢？依據簡單使用原則的框架是強制使用策略的最好方法。通過jar文件與javadoc之類的可執行工件與開發人員對話比白紙和幻燈片更輕易表示架構準則。
　　
　　然而，你不能要求開發團隊直到異常處理策略及附加的框架支持預備完畢后才開始錯誤處理。錯誤處理必須在第一個源文件創建時確定。一個好的啟動方法是定義基礎的異常層次。
　　
　　基礎異常層次
　　
　　我們首要的任務是定義一個可以跨項目的通用異常層次。這里的非強制異?；愂荱nrecoverableException，由于歷史原因，這個名字可能會有些誤導。你可以在自己的層次中使用更好的名字
　　
　　當你不想使用強制異常時WrappedException可以提供一種簡單通用的傳送機制：包裹原來的異常并重新拋出。WrappedException保存原始異常作為內部引用，這使得當類需要原始異常時也可以可以正常工作。當這不重要時，你可以使用SerializableException，他類似于WrappedException，此外還可以在客戶端沒有對類庫作任何假設的情況下使用。
　　
　　雖然我們偏好和推薦非強制異常，但你可以保留強制異常作為可選項。InstrumentedException是一個支持強制非強制異常的接口，他遵循一定屬性實現模式。他答應異常處理者一致地檢查來源頁不需要考慮是來自強制或非強制的異常。
　　
　　下面的類圖顯示了我們基礎的異常層次。
　　　 J2EE中的異常治理及錯誤跟蹤框架一(圖)（圖一）

　　這時候我們已經擁有了一個策略及相應的一組可以被拋出的異常?，F在是時候建立安全網了。
　　
　　防守的底線
　　
　　“創建應用范圍的用戶會話”這篇文章描述了Rampart，一個使用了由企業信息系統層，基于無狀態會話bean的業務層及基于網頁和標準J2SE客戶端的客戶層的分層架構。異?？梢詮娜我鈱哟螔伋?，可以在線處理或者延遲到調用鏈的最終端。J2SE和J2EE應用服務器都可以通過捕捉未處理的Errors和RuntimeExceptions來抵御侵入性的行為，通過輸出棧信息、記入日志或者執行其他默認的操作。在任何情況下，用戶都不應該看到輸出信息，通常是沒有意義的甚至影響程序穩定性的錯誤。因此我們必須構建自己的壁壘來提供更好的異常處理機制來維持這一防守的底線
　　
　　看一下圖2:
　　　 J2EE中的異常治理及錯誤跟蹤框架一(圖)（圖二）

　　異常可能發生在EJB層的服務端和網頁層，甚至獨立的客戶端。在第一種情況下，異常停留在同一VM中，也可能被傳送到網頁層。這兒就是我們要安裝的頂層異常處理器的地方。
　　
　　在后一種情況下，異常發生在EJB容器的邊緣并且通過RMI連接傳遞到客戶端。必須注重不要傳送任何屬于服務端類的異常（如來自對象關系映射框架這類的）到客戶端。而由EJB異常處理器通過使用SerializableException作為中介來處理這個問題。在客戶端，頂層的Swing異常處理器捕捉其他未處理的錯誤并采取相應措施。
　　
　　異常處理框架
　　
　　在Rampart框架中異常處理器是一個實現了ExceptionHandler接口的類。這個接口僅有一個包含兩個參數（待處理的Throwable和當前的Thread）的方法。方便起見，框架提供了包含基本的實現類ExceptionHandlerBase，他辨別Throwable并將其代理給RuntimeException, Error, Throwable和Rampart框架的Unrecoverable的特定的抽象方法來處理。子類提供這些方法的實現并區別處理。
　　
　　下面的類圖顯示了異常處理器的層次和三個缺省的異常處理器。
　　 J2EE中的異常治理及錯誤跟蹤框架一(圖)（圖三）