為你的網站定制一套統一的異常處理機制

寫過程序的人都知道，再好的程序都可能存在未能處理的異常情況，因為程序運行的環境和人員的操作方式可以說是千差萬別，開發人員在一開始很難把所有的情況都想到，並做相應的處理。所以，開發人員才需要配合測試人員進行協同工作，目的就是盡量較少和消滅（完全消滅當然只是理想情況了）程序中的錯誤，處理盡可能多的異常情況。在各種應用程序中，網站面臨的挑戰可以說是各類程序中比較大的了。為什麼這麼說呢？原因很簡單，一個網站的用戶千差萬別，用戶習慣各不相同，用戶所使用的電腦和軟件平台也各異，網絡環境更是大相徑庭，所以網站發生異常情況的幾率也是比較大的。既然異常不可避免，但我們應該為我們的網站制定一套異常處理機制，即如何更合理的為已經發生的異常善後。本文的討論僅限於.NET環境的網站開發中的異常處理，其他平台的道理應該是一樣的，只是具體的實現方式不同而已。

其實大部分異常無非分為兩大類，第一類是你知道可能會發生的，即開發人員在寫程序的時候就已經知道可能會發生的一些意外情況。這種情況的異常又可以分為如下幾種情況：其一，異常的發生不會影響程序的正常執行，只需要把這個異常正確捕獲到，並做相應的處理即可；其二，異常一旦發生，程序無法完成正常的處理邏輯，這個時候需要跳轉異常處理邏輯上來，提示或者通知管理員或者最終用戶目前發生的情況。以便管理員或者用戶做相應的處理以後才能正常執行程序邏輯。舉個例子，用戶想查詢數據庫中的某條數據記錄，當程序試圖連接目標數據庫的時候發現數據庫服務器Down機了，正常的查詢操作已經沒有辦法繼續。這就要求程序在處理像連接數據庫這樣的操作的時候，先要判斷數據庫是否運行正常，一旦捕獲到數據庫運行異常，應該立即記錄錯誤日志並報告數據庫管理員，同時給予用戶友好的提示；其三，有的異常是正常處理邏輯的需要。比如.NET中Thread.Abort()就會引發一個ThreadAbortException，調用Response.End(), Response.Redirect(), Response.Transfer()的時候也會引發一個ThreadAbortException，這些都是用於控制正常邏輯的。這類異常一般不需要你做太多額外的處理。值得注意的是：我們在寫自己的程序的時候，盡量不要把異常當成正常處理邏輯的一部分，這樣會導致程序執行效率低下。舉個例子：

int　temp　=　0;

try
{
temp　=　Int32.Parse(input);
}
catch
{
temp　=　1;　　//　1是默認值
}

上面這段代碼就把異常處理當成了正常處理邏輯的一部分，這樣會使得程序執行效率低下。上面這段代碼寫成如下形式會好些：

int　temp　=　0;

if(Int32.TryParse(input,　out　temp)　==　false)
{
temp　=　1;　//　1是默認值
}

現在接著上面的說，除去第一類異常外，還有一種異常即第二類異常是程序開發人員在一開始沒有想到的一些異常情況，已經超出了程序編寫人員的處理范圍。這類異常是很致命的，一旦發生，對系統將造成很大影響。因為到了這個時候，程序已經的運行已經不在我們的控制范圍內了。

對於第一類異常，程序員基本都已經將他們就地解決了。對於第二類異常，就需要為其建立一個統一的處理機制。對於一個中等規模以上的網站來說，業務邏輯是比較復雜的，涉及的網頁也很多。我們事先不知道哪個頁面或者哪段程序會出異常（至少在程序開發的時候沒有完全想到的一些異常），所以才需要有這樣一套統一的異常處理機制。這裡討論兩種可行的辦法，第一種辦法是為網站所有的頁面創建一個基類，基類繼承自System.Web.UI.Page，在基類裡面統一處理各類異常情況。實現方式是為基類添加一個異常處理事件，即this.Error += new System.EventHandler(this.PageBase_Error); 把你的異常處理邏輯實現在方法PageBase_Error中。

protected　void　PageBase_Error(object　sender,　System.EventArgs　e)
{

　　　　　　　　　　　　 Exception　currentError　=　Server.GetLastError();

　　　　　　　　　　　　 if　(currentError　==　null)
　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　 return;
　　　　　　　　　　　　 }

　　　　　　　　　　　　 LogError(currentError);　　//　把錯誤信息寫到你的日志列表裡面，也可以同時給系統管理員發送一封郵件。

　　　　　　　　　　　　 string　friendlyMsg　=　"你的友好錯誤提示";

#if　DEBUG　　//　如果程序處於Debug狀態，則直接在頁面顯示具體錯誤信息，便於調試

　　　　　　　　　　　　 friendlyMsg　=　currentError.Message　+　“<br　/>Stack:　”　+　currentError.　StackTrace;

#endif

　　　　　　　　　　　　 //　下面的信息是顯示給用戶的友好提示信息

　　　　　　　　　　　　 Response.Write(friendlyMsg);　　//　你也可以重定向到某個錯誤提示頁面。這裡要小心一點的是，確保你的錯誤提示頁面絕對不要有個Bug，否則可能會形成死循環。所以，錯誤提示頁面最好就是一張完全靜態的HTML頁面。

　　　　　　　　　　　　 Server.ClearError();

}