本文實例總結了asp.net開發中常見公共捕獲異常方式。分享給大家供大家參考，具體如下：
前言：在實際開發過程中，對于一個應用系統來說，應該有自己的一套成熟的異常處理框架，這樣當異常發生時，也能得到統一的處理風格，將異常信息優雅地反饋給開發人員和用戶。我們都知道，.net的異常處理是按照“異常鏈”的方式從底層向高層逐層拋出，如果不能盡可能地早判斷異常發生的邊界并捕獲異常，CLR會自動幫我們處理，但是這樣系統的開銷是非常大的，所以異常處理的一個重要原則是“早發現早拋出早處理”。但是本文總結的服務端公共捕獲異常處理可以寬泛地看做是在表現層的操作，要捕獲特定層的特定異常，不在討論范圍內。
1、BasePage類處理方式
在頁面的公共基類里重寫OnError事件。在前面這篇《asp.net實現非常實用的自定義頁面基類》里，樓豬已經貼了代碼，就不再費事了。根據經驗，很多人開發的時候幾乎都這么寫，而且對調試和維護還是很有幫助的。需要說明的是，每新添一個頁面，其對應類都必須繼承自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也不是不可以，只能說明我們對待異常的態度太草率了。為了顯得我們的專業和全面，請參考其他異常處理專業性文章研讀一番，相比異常處理的核心思想（異常處理的“大智慧”），這篇文章總結的（異常處理的“小技巧”）對初學者而言可能也是誤導之作，請務必留意甄別。
完整實例代碼代碼點擊此處本站下載。
希望本文所述對大家asp.net程序設計有所幫助。
