對於一個Web應用程序來說出錯是在所難免的因此我們應該未雨綢缪為可能出現的錯誤提供恰當的處理事實上良好的錯誤處理機制正是衡量Web應用程序好壞的一個重要標准試想一下當用戶不小心在浏覽器輸入了錯誤的URL或者當用戶提供了一些信息導致程序出錯的時候如果我們沒有對這些情況進行處理而是任由或是的錯誤頁面甚至出錯的堆棧信息呈現在用戶面前這無疑會把一些用戶給嚇跑所以在我們開發Web應用程序的時候應該對錯誤處理機制有充分的了解
讓我們回到ASPNET上來先提兩個問題讓大家思考一下ASPNET為我們提供了幾種錯誤處理機制呢？如果同時采用了幾種錯誤處理機制它們之間是否存在一定的優先級呢？帶著這個問題我們先來看一下我們最常見的WebConfig文件
<?xml version=?>
<configuration>
<systemweb>
<customErrors mode=On defaultRedirect=>
<error statusCode= redirect= />
<error statusCode= redirect= />
</customErrors>
</systemweb>
</configuration>
對於<customErrors>這個設置項我想無需多言了詳情可以參考MSDN的第一種錯誤處理機制——使用WebConfig的<customErrors>配置項應該是大家最常用的
接著我們再看另外一個也很常用的文件Globalasax提到這個文件大家想到了什麼呢？對就是跟兩大Web應用程序對象（ApplicationSession）相關的事件了在這些事件當中有一個屬於Application范疇的與錯誤相關的事件——Error而對應的事件處理方法就是Application_Error了顧名思義這個事件處理方法在應用程序級別錯誤發生的時候就會被調用因此你可以在這個方法中添加代碼來對錯誤進行處理如下所示
protected void Application_Error(object sender EventArgs e) {
Exception objErr = ServerGetLastError()GetBaseException();
ResponseWrite(Error: + objErrMessage);
ServerClearError();
}
在這裡大家要注意最後一句代碼的使用ServerClearError()為什麼要使用這句代碼呢？如果不用又會怎樣呢？在這裡我又先賣個關子好了第二種錯誤處理機制——使用Globalasax中的Application_Error事件處理方法也登台亮相了
以上這兩種錯誤處理方法都可以說是全局性的一個源自應用程序配置文件一個則是必須放在應用程序根目錄下的Globalasax文件的事件處理方法與全局相對的就是局部所以我們很自然的就會想有沒有應用於局部——某個頁面的錯誤處理機制呢？答案是有的而且還有兩種————使用ErrorPage屬性以及使用Page_Error事件處理方法對於第一種機制你幾乎可以在任何時候設置ErrorPage屬性從而確定頁面發生錯誤的時候會重定向至哪個頁面對於第二種機制而言它與Application_Error事件處理方法是很類似的只不過被觸發的時機不同而已以下是具體的兩個例子
<script language=C# runat=server>
protected void Page_Load(object sender EventArgs e) {
thisErrorPage = ;
}
</script>
protected void Page_Error(object sender EventArgs e) {
Exception objErr = ServerGetLastError()GetBaseException();
ResponseWrite(Error: + objErrMessage);
ServerClearError(); //同樣要注意這句代碼的使用
}
至此四種錯誤處理機制已經悉數登場是時候給它們排個名次了從優先級高到低排序Page_Error事件處理方法 > ErrorPage屬性 > Application_Error事件處理方法 > <customErrors>配置項雖然排序是這樣但是這個排序之間又有微妙的關系首先要讓ErrorPage屬性能夠發揮作用<customErrors>配置項中的mode屬性必須設為On其次雖然Page_Error事件處理方法排在最前面但是如果少掉了ServerClearError()方法的話仍然會引發優先級較低的錯誤處理這種情況對於Application_Error事件處理方法也是如此順序是排好了但是順序卻不是最重要的問題甚至可以說是沒有太多意義的問題因為在很多情況下你可能並不會混合使用這四種處理機制我想最重要的問題還是在如何選用這些錯誤處理機制上對於這個問題希望有經驗的朋友能夠談談看法
好了關於ASPNET的四種錯誤處理機制就介紹到這裡也該說說自己的一些感受了ASPNET的設計者確實站在開發者的角度作了周全的考慮因此提供了多達四種的錯誤處理機制供我們選用這一點是值得稱道的但是套用一句廣告詞——多則惑我們也會被這麼多的錯誤處理機制弄得有些頭暈對照JEE領域中的錯誤處理我們可以發現會相對簡單一些首先是對應<customErrors>的設置我們也可以從JEE項目最常用的webxml文件中找到類似的配置項<errorPage>其次在JEE的領域中Page並不是一個重要的實體而且事件驅動模型也不是必需的所以我還真的找不到與Application_Error和Page_Error方法對應處理機制最後在JEE的領域中更多強調的是Request和Response一旦在邏輯處理中出現了錯誤我們可以很容易地通過RequestDispatcher將Request分發到相應的錯誤處理模塊中事實上這是非常靈活的一種處理方式有興趣的朋友不妨了解一下
From:http://tw.wingwit.com/Article/program/net/201311/12225.html
