對於一個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＞
