整理asp.net開發中幾種常見公用捕獲異常方式

前言：在實際開發過程中，對於一個應用系統來說，應該有自己的一套成熟的異常處理架構，這樣當異常發生時，也能得到統一的處理風格，將異常資訊優雅地反饋給開發人員和使用者。我們都知道，.net的異常處理是按照“異常鏈”的方式從底層向高層逐層拋出，如果不能儘可能地早判斷異常發生的邊界並捕獲異常，CLR會自動幫我們處理，但是這樣系統的開銷是非常大的，所以異常處理的一個重要原則是“早發現早拋出早處理”。但是本文總結的服務端公用捕獲異常處理可以寬泛地看做是在表現層的操作，要捕獲特定層的特定異常，不在討論範圍內。

1、BasePage類處理方式
在頁面的公用基類裡重寫OnError事件。在這篇文章裡，樓豬已經貼了代碼，就不再費事了。根據經驗，很多人開發的時候幾乎都這麼寫，而且對調試和維護還是很有協助的。需要說明的是，每新添一個頁面，其對應類都必須繼承自BasePage類異常處理才起作用。

2、Global.asax處理方式
如1中所述，BasePage類的異常處理要求每一個aspx類檔案都繼承它，適用性和效能顯然會打折扣。而Global.asax檔案定義了asp.net應用程式中的所有應用程式物件共有的方法、屬性和事件，我們可以不採用BasePage的處理方式，在Global.asax裡實現Application_Error事件並處理也可以。下面模仿BasePage類裡的處理異常方法，實現如下：

代碼

   /// <summary>
        /// 出錯處理:寫日誌,導航到公用出錯頁面
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        protected void Application_Error(object sender, EventArgs e)
        {
            if (Server.GetLastError() == null) return;
            Exception ex = Server.GetLastError().GetBaseException();
            string error = this.DealException(ex);
            DotNet.Common.Util.Logger.WriteFileLog(error, HttpContext.Current.Request.PhysicalApplicationPath + "LogFile");
            if (ex.InnerException != null)
            {
                error = this.DealException(ex);
                DotNet.Common.Util.Logger.WriteFileLog(error, HttpContext.Current.Request.PhysicalApplicationPath + "LogFile");
            }
            this.Server.ClearError();
            this.Response.Redirect("/Error.aspx");
        }

        /// <summary>
        /// 處理異常，用來將主要異常資訊寫入文本日誌
        /// </summary>
        /// <param name="ex"></param>
        /// <returns></returns>
        private string DealException(Exception ex)
        {
            this.Application["StackTrace"] = ex.StackTrace;
            this.Application["MessageError"] = ex.Message;
            this.Application["SourceError"] = ex.Source;
            this.Application["TargetSite"] = ex.TargetSite.ToString();
            string error = string.Format("URl：{0}\n引發異常的方法：{1}\n錯誤資訊：{2}\n錯誤堆棧：{3}\n",
                this.Request.RawUrl, ex.TargetSite, ex.Message, ex.StackTrace);
            return error;
        }

 上面方式的好處是，寫一次代碼，應用程式發生的大部分異常它都給你捕捉處理了。樓豬要在這裡由衷地發一番感慨，感謝ms為我們提供了這麼優秀的架構，太省事了吧。

3、IHttpModule介面處理
1和2的處理方式大家都是非常熟悉的，樓豬在實際開發中基本上都是遵循上面兩種寫法，而且樓豬因為有了2中這種大小通吃的處理方式，甚至已經激動地感謝ms了。但是，在asp.net程式調用線程進行非同步處理的時候，容易發生在後台線程或線程池裡拋出的異常並不能被1或（和）2完全捕捉到，這就涉及到asp.net下未捕獲異常的處理。也就是說樓豬以前做過的很多大小項目中對異常的處理是不完備的。這難道是nc樓豬沒有先謝國家種下的惡果嗎？感謝國家，感謝ms，感謝部落格園，感謝無私的xdjm，感謝自己......
asp.net下未捕獲異常的處理步驟如下：
（1）、建立一個實現IHttpModule介面的類

代碼

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text;

namespace DotNet.Common.WebForm
{
    using DotNet.Common.Util;

    /// <summary>
    /// 通用未捕獲異常處理 
    /// </summary>
    public class AspNetUnhandledExceptionModule : IHttpModule
    {
        static object syncObj = new object();
        static bool isInit = false;

        public AspNetUnhandledExceptionModule()
        {
        }

        #region IHttpModule Methods

        public void Init(HttpApplication context)
        {
            lock (syncObj)
            {
                if (!isInit)
                {
                    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(OnUnhandledException);
                    isInit = true;
                }
            }
        }

        public void Dispose()
        {
        }

        #endregion

        #region OnUnhandledException

        void OnUnhandledException(object o, UnhandledExceptionEventArgs e)
        {
            if (e.ExceptionObject == null) return;
            Exception ex = e.ExceptionObject as Exception;
            string error = string.Format("引發異常的方法：{0}\n錯誤資訊：{1}\n錯誤堆棧：{2}\n",
                           ex.TargetSite, ex.Message, ex.StackTrace);
            Logger.WriteFileLog(error, AppDomain.CurrentDomain.BaseDirectory + "LogFile");
        }

        #endregion
    }
}

 （2）、web.config節點配置

    <httpModules>
      <add name="AspNetUnhandledExceptionModule" type="DotNet.Common.WebForm.AspNetUnhandledExceptionModule, DotNet.Common.WebForm"></add>
    </httpModules>

最後貼出測試代碼：

代碼

    protected void Page_Load(object sender, EventArgs e)
        {
            if (!IsPostBack)
            {
                System.Threading.ThreadPool.QueueUserWorkItem(new System.Threading.WaitCallback(Test), null);
            }
        }
        protected void Test(object state)
        {
            int[] numArr = new int[100];
            numArr[100] = 100; //異常
        }

 需要說明的是，通過線程或者線程池處理的程式，在發生異常時，每個線程都會有它自己獨立的上下文，所以HttpContext對象應儘可能少地出現在異常處理階段。

小結：不知道還有多少童鞋認為異常處理就是在代碼裡try...catch一下，拋出異常然後完事？如果有的話，呵呵，當年樓豬是拿“沒有人天生就是十全十美的”這句話來安慰自己的。當然了，try...catch也不是不可以，只能說明我們對待異常的態度太草率了。為了顯得我們的專業和全面，請參考其他異常處理專業性文章研讀一番，相比異常處理的核心思想（異常處理的“大智慧”），這篇文章總結的（異常處理的“小技巧”）對初學者而言可能也是誤導之作，請務必留意甄別。

demo下載：demo