ASP.NET的錯誤處理機制 ~

        對於一個Web應用程式來說，出錯是在所難免的，因此我們應該未雨綢繆，為可能出現的錯誤提供恰當的處理。事實上，良好的錯誤處理機制正是衡量Web應用程式好壞的一個重要標準。試想一下，當使用者不小心在瀏覽器輸入了錯誤的URL或者當使用者提供了一些資訊導致程式出錯的時候，如果我們沒有對這些情況進行處理，而是任由404或是500的錯誤頁面甚至出錯的堆棧資訊呈現在使用者面前，這無疑會把一些使用者給嚇跑。所以，在我們開發Web應用程式的時候，應該對錯誤處理機制有充分的瞭解。
   
        讓我們回到ASP.NET上來，先提兩個問題讓大家思考一下：ASP.NET為我們提供了幾種錯誤處理機制呢？如果同時採用了幾種錯誤處理機制，它們之間是否存在一定的優先順序呢？帶著這個問題，我們先來看一下我們最常見的Web.Config檔案：

 

<?xml version="1.0"?>
    <configuration>
        <system.web>
            <customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
                <error statusCode="403" redirect="Error403.htm" />
                <error statusCode="404" redirect="Error404.htm" />  
            </customErrors>
        </system.web>
    </configuration>

 

對於<customErrors>這個設定項，我想無需多言了，詳情可以參考MSDN的。第一種錯誤處理機制——使用Web.Config的<customErrors>配置項應該是大家最常用的。
        接著，我們再看另外一個也很常用的檔案：Global.asax。提到這個檔案，大家想到了什麼呢？對，就是跟兩大Web應用程式物件（Application、Session）相關的事件了。在這些事件當中，有一個屬於Application範疇的與錯誤相關的事件——Error，而對應的事件處理方法就是Application_Error了。顧名思義，這個事件處理方法在應用程式層級錯誤發生的時候就會被調用，因此你可以在這個方法中添加代碼來對錯誤進行處理，如下所示：

 

protected void Application_Error(object sender, EventArgs e) {
    Exception objErr = Server.GetLastError().GetBaseException();
    Response.Write("Error:" + objErr.Message);
    Server.ClearError();
}

 

在這裡，大家要注意最後一句代碼Server.ClearError()的使用，為什麼要使用這句代碼呢？如果不用又會怎樣呢？在這裡我又先賣個關子。好了，第二種錯誤處理機制——使用Global.asax中的Application_Error事件處理方法也登台亮相了。

        以上這兩種錯誤處理方法都可以說是全域性的，一個源自應用程式設定檔，一個則是必須放在應用程式根目錄下的Global.asax檔案的事件處理方法。與全域相對的就是局部，所以我們很自然的就會想：有沒有應用於局部——某個頁面的錯誤處理機制呢？答案是“有的”，而且還有兩種————使用ErrorPage屬性以及使用Page_Error事件處理方法。對於第一種機制，你幾乎可以在任何時候設定ErrorPage屬性，從而確定頁面發生錯誤的時候會重新導向至哪個頁面；對於第二種機制而言，它與Application_Error事件處理方法是很類似的，只不過被觸發的時機不同而已。以下是具體的兩個例子：

 

<script language="C#" runat="server">
    protected void Page_Load(object sender, EventArgs e) {
        this.ErrorPage = "ErrorPage.htm";
        
    }   
</script>

 

 

 

protected void Page_Error(object sender, EventArgs e) {
    Exception objErr = Server.GetLastError().GetBaseException();
    Response.Write("Error:" + objErr.Message);
    Server.ClearError(); //同樣要注意這句代碼的使用
}    

 

        至此，四種錯誤處理機制已經悉數登場，是時候給它們排個名次了。根據優先順序從高到低排序：Page_Error事件處理方法 > ErrorPage屬性 > Application_Error事件處理方法 >  <customErrors>配置項。雖然排序是這樣，但是這個排序之間又有微妙的關係。首先，要讓ErrorPage屬效能夠發揮作用，<customErrors>配置項中的mode屬性必須設為"On"；其次，雖然Page_Error事件處理方法排在最前面，但是，如果少掉了Server.ClearError()方法的話，仍然會引發優先順序較低的錯誤處理，也就是說ErrorPage屬性等錯誤處理機制仍然會發揮作用，這樣就得不到你想要的結果了。這種情況對於Application_Error事件處理方法也是如此。順序是排好了，但是順序卻不是最重要的問題，甚至可以說是沒有太多意義的問題，因為在很多情況下，你可能並不會混合使用這四種處理機制。我想，最重要的問題還是在如何選用這些錯誤處理機制上。對於這個問題，希望有經驗的朋友能夠談談看法。
   
        好了，關於ASP.NET的四種錯誤處理機制就介紹到這裡，也該說說自己的一些感受了。ASP.NET的設計者確實站在開發人員的角度作了周全的考慮，因此提供了多達四種的錯誤處理機制供我們選用，這一點是值得稱道的。但是套用一句廣告詞——多則惑，我們也會被這麼多的錯誤處理機制弄得有些頭暈。對照J2EE領域中的錯誤處理，我們可以發現會相對簡單一些。首先是對應<customErrors>的設定，我們也可以從J2EE項目最常用的web.xml檔案中找到類似的配置項：<errorPage>；其次，在J2EE的領域中，Page並不是一個重要的實體而且事件驅動模型也不是必需的，所以我還真的找不到與Application_Error和Page_Error方法對應的處理機制；最後，在J2EE的領域中，更多強調的是Request和Response，一旦在邏輯處理中出現了錯誤，我們可以很容易地通過RequestDispatcher將Request分發到相應的錯誤處理模組中，事實上這是非常靈活的一種處理方式，有興趣的朋友不妨瞭解一下。