推薦：J2EERI Pointbase數據庫遠程命令執行漏洞
信息提供： 安全公告（或線索）提供熱線：51cto.editor@gmail.com 漏洞類別： 設計錯誤 攻擊類型： 嵌入惡意代碼 發布日期： 2003-12

　　回顧一下你上一個J2EE工程，是否遇到過類似錯誤沒有記入日志或者被多次記錄的情況?是否只是因為在某處代碼吃 掉了異常導致你花費無數次時間來跟蹤一個bug?是否你的用戶直接看到了堆棧的跟蹤信息?如果這樣的話，你可能需要一種通用的異常管理的策略和一些補充的 代碼。 這篇文章為你提供了在J2EE項目中通過使用錯誤處理框架使用一些策略的基礎。

Java中關于異常處理的爭論可以被認為是一種信仰上的爭執:一方面，強制異常(checked exceptions)的支持者認為調用者應該處理他們調用代碼出現的異常;另一方面，非強制(unchecked exceptions)異常的追隨者認為強制異常混亂了代碼，而且通常客戶端不能立即處理，那為什么還要檢查他呢。

作為初級工程師，我們首先信奉的是強制異常，但幾年后，在使用N久的try/catch/finally后，我們開始轉向非強制異常了。因為我們開始相信一些處理錯誤狀況的基本規則:

如果需要處理異常，那么就處理

如果處理不了，就拋出

如果拋不了，就用非強制的基類異常包裝后再拋出

但這些異常被拋到最頂層時會怎么樣呢?對這種情況，我們有一個底線確保錯誤信息被記錄并且用戶得到正確的提示。

本文提供了另外一種框架來處理異常，它擴展了“Create an Application-Wide User Session for J2EE”所提出的企業應用session工具。使用此框架的J2EE應用將:

總是向用戶提供有意義的錯誤信息

記下未處理的錯誤環境，并且只記錄一次

在日志文件中用唯一的請求ID號對異常進行編號，以便進行高精度的調試

在各層中設置一個強壯的、可擴展的，而又簡單的策略來處理異常

為了搭建框架，我們運用了面向狀態編程(AOP，aspect-oriented programming)、設計模式和使用XDoclet進行代碼生成。

為什么我們需要通用的錯誤處理方法

在項目的開始，我們會做一些關鍵性的系統架構決定，如:系統中的元素如何交互?會話狀態保存在哪兒?哪種通信協議會被使用等等。但這里并沒有包含錯誤處理。因而每個開發人員都可以任意決定如何定義、分類、建模和處理錯誤。作為一個開發人員，你可以想象在這種方式下的結果:

1. 臃腫的日志:每個try/catch都包含log語句，這導致被污染的代碼生成臃腫和多余的日志入口。

2. 多余的實現:同一類型的錯誤有不同的表示，這導致處理的復雜化。

3. 破碎的封裝:來自其他組件的異常被定義為方法標識的一部分，這導致接口和實現的分離被打破了。

4. 不明確的異常定義:方法簽名通常采用拋出java.lang.Exception，這導致客戶端不能明確得到方法錯誤的語義。

通常沒有定義異常處理策略的借口是:java已經提供了異常處理。這是事實，java也提供一貫的定義、通信、傳播及響應異常的工具。但開發人員需要決定如何在實際的項目中使用這些服務。幾個方面是必須要考慮的，如:

1. 檢查或不檢查異常:是否應該檢查或不檢查新異常類?

2. 異常的使用者:究竟是誰需要知道什么時候會發生未處理的異常及由誰來負責記錄及通知操作人員?

3. 基礎的異常層次:異常需要包含什么信息及異常層次需要反映什么語義?

4. 傳遞;是否未處理的異常會被定義或傳遞給別的異常類，及他們如何在分布式環境中傳遞?

5. 解釋:未處理的異常如何被解釋為可閱讀的，甚至支持多語言的信息?

在框架中封裝規則，要快!

我們給出的通用異常處理策略是基于如下的因素:

使用非強制的異常:使用強制異常，調用者要被迫處理他們幾乎不能處理的錯誤。非強制的異常則給調用者一個選擇。在使用第三方類庫時，你不能控制 異常是強制或非強制的。這種情況下，你需要用非強制異常來包含強制異常。在使用非強制異常時，最大的讓步是你不能再強制調用者來處理異常了。然而作為接口 定義的一部分，異常仍是約定的關鍵部分并且繼續成為Javadoc文檔的一部分。 　　

分享：學習JSP的經典的入門學習資料
　一、 JSP 技術概述 　　在 Sun 正式發布 JSP(JavaServer Pages) 之后，這種新的 Web 應用開發技術很快引起了人們的關注。 JSP 為創建高度動態的 Web 應用提供了一個獨特的開發環境。