ASP.NET MVC下自定義錯誤頁和展示錯誤頁的幾種方式
在網站運行中，錯誤是不可避免的,錯誤頁的產生也是不可缺少的。
這幾天看了博友的很多文章，自己想總結下我從中學到的和實際中配置的。
首先，需要知道產生錯誤頁的來源，一種是我們的.NET平臺拋出的，一種是網站所依賴的宿主拋出的，一般來講我們所依賴的宿主就是IIS了。
IIS中的錯誤頁入口：
其中的錯誤碼想必並不陌生
這裏是在服務器上找不到所需資源時拋出的錯誤頁,在這裏可以設置需要展示的錯誤頁面，只需將預定的錯誤頁面加入服務器中，然後在指定狀態碼下配置路徑即可。
這是請求在IIS中時，還未完全進入到asp.net mvc中，這裏需要理解什麽是未完全進入，IIS7+的版本中,不依賴於請求路徑末尾的標識信息，利用mvc中的urlRoutingModule進行處理，在我們配置mvc的路由時,首先的第一條：
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
便是隔離非mvc內部的使用文件，如果請求的只是服務器上的文件，那麽路由便會在這裏進行過濾，使之不匹配具體路由信息。
也就只是和mvc打了個招呼 然後就走了,沒有進入mvc中搞事情。
第二種是,進入了asp.net mvc的管轄範圍，然後在其中出錯了，便是跳到我們在程序中配置的錯誤頁了。
首先講講我從博友那裏學到的、看到的幾種方式。
第一種是在web.config中通過customError配置。
<customErrors mode="On" defaultRedirect="~/Error/ErrorPage"> <error statusCode="404" redirect="~/Error/ErrorPage404" /> </customErrors>
但是這種方式不怎麽令人接受，太過於簡單，沒有一點異常信息，並且有時候還不能起效果，我不太喜歡這種方式。
這種是用框架封裝好的，利用的是將要說的第三種的強大方式實現的,當有異常發生又沒得捕獲時，最終利用的第三種方式自動實現。
第二種是利用HandlerErrorAttribute 特性，利用AOP的方式，當有異常出現時，便會進入具體實現了這個特性的，且被註冊了的ExceptionAttribute職責中。
namespaceSAssassin.Web.Core.Filter { /// <summary> /// 異常處理之日誌記載采用消息隊列方式 /// </summary> public class MyExceptionAttribute : HandleErrorAttribute { public static Queue<Exception> ExceptionQueue = new Queue<Exception>(); public override void OnException(ExceptionContext filterContext) { ExceptionQueue.Enqueue(filterContext.Exception); filterContext.HttpContext.Response.Redirect("~/ErrorPage/CustomErrorPage"); base.OnException(filterContext); } } }
在這裏，我可以得到異常信息，也可以解析具體的異常報錯原因，比如404，500... 可以通過這種形勢，將其轉移到不同的自定義錯誤頁面上，此處我增加了一個控制器
CustomErrorPageController,專門用來存放錯誤頁面，原有的Shared下的Error.cshtml錯誤頁面也仍然存在著。
我比較喜歡這種方式，一來可以看到異常信息，而來可以設計需要跳轉的錯誤頁面。
第三種方式也是最強大的、俗稱"最後一道防線"，從全局層面去捕捉異常的Application_Error
當網站初次啟動時，會執行一個特殊的動作,Application_start 首先執行，也只初始化一次。這個也是Application 中的事件。
// // 摘要: // ASP.NET 將 HTTP 標頭發送到客戶端之前發生。 public event EventHandler PreSendRequestHeaders; // // 摘要: // 在選擇該處理程序對請求作出響應時發生。 public event EventHandler MapRequestHandler; // // 摘要: // 釋放應用程序時發生。 public event EventHandler Disposed; // // 摘要: // 作為執行的 HTTP 管道鏈中的第一個事件發生，當 ASP.NET 的請求做出響應。 public event EventHandler BeginRequest; // // 摘要: // 當安全模塊已建立的用戶標識時出現。 public event EventHandler AuthenticateRequest; // // 摘要: // 當安全模塊已建立的用戶標識時出現。 public event EventHandler PostAuthenticateRequest; // // 摘要: // 安全模塊已驗證用戶身份驗證時發生。 public event EventHandler AuthorizeRequest; // // 摘要: // 當前請求的用戶已被授權時發生。 public event EventHandler PostAuthorizeRequest; // // 摘要: // 當 ASP.NET 完成授權事件以便從緩存中，跳過的事件處理程序 （例如，一個頁面或 XML Web 服務） 執行的請求提供服務的緩存模塊時發生。 public event EventHandler ResolveRequestCache; // // 摘要: // ASP.NET 將繞過當前事件處理程序的執行，並允許緩存模塊以處理從緩存請求時發生。 public event EventHandler PostResolveRequestCache; // // 摘要: // ASP.NET 將內容發送到客戶端之前發生。 public event EventHandler PreSendRequestContent; // // 摘要: // 當 ASP.NET 已映射到相應的事件處理程序的當前請求時出現。 public event EventHandler PostMapRequestHandler; // // 摘要: // 當 ASP.NET 已完成處理的事件處理程序時發生 System.Web.HttpApplication.LogRequest 事件。 public event EventHandler PostLogRequest; // // 摘要: // 已釋放與請求相關聯的托管的對象時發生。 public event EventHandler RequestCompleted; // // 摘要: // 獲取與當前的請求相關聯的請求狀態 （例如，會話狀態） 時發生。 public event EventHandler PostAcquireRequestState; // // 摘要: // ASP.NET 開始執行事件處理程序 （例如，一個頁面或 XML Web 服務） 之前發生。 public event EventHandler PreRequestHandlerExecute; // // 摘要: // 當 ASP.NET 事件處理程序 （例如，一個頁面或 XML Web 服務） 完成執行時發生。 public event EventHandler PostRequestHandlerExecute; // // 摘要: // ASP.NET 完成執行所有請求事件處理程序後發生。 此事件會導致狀態模塊保存當前的狀態數據。 public event EventHandler ReleaseRequestState; // // 摘要: // 當 ASP.NET 已完成執行所有請求事件處理程序和存儲數據的請求狀態時發生。 public event EventHandler PostReleaseRequestState; // // 摘要: // 當 ASP.NET 完成執行事件處理程序，以便讓緩存模塊存儲將用於為從緩存中的後續請求提供服務的響應時發生。 public event EventHandler UpdateRequestCache; // // 摘要: // 當 ASP.NET 完成更新的緩存模塊和存儲用於為從緩存中的後續請求提供服務的響應時發生。 public event EventHandler PostUpdateRequestCache; // // 摘要: // ASP.NET 執行當前請求的任何日誌記錄之前發生。 public event EventHandler LogRequest; // // 摘要: // 當 ASP.NET 獲取與當前的請求相關聯的當前狀態 （例如，會話狀態）。 public event EventHandler AcquireRequestState; // // 摘要: // 作為執行的 HTTP 管道鏈中的最後一個事件發生，當 ASP.NET 的請求做出響應。 public event EventHandler EndRequest; // // 摘要: // 當引發未處理的異常時發生。 public event EventHandler Error;
看到最後一個事件，當引發未處理的異常時發生，便是最後一道防線登場了。如果沒有用aop的方式捕捉異常，那麽就是Application _Error登場了。
在Global.asax中我們可以寫上這個方法
/// <summary> /// 可以完成全局異常處理 /// </summary> /// <param name="sender"></param> /// <param name="e"></param> protected void Application_Error(object sender, EventArgs e) { // 在出現未處理的錯誤時運行的代碼 var error = Server.GetLastError(); var code = (error is HttpException) ? (error as HttpException).GetHttpCode() : 500; //如果不是HttpException記錄錯誤信息 if (code != 404) { //此處郵件或日誌記錄錯誤信息 } Response.Write("出錯"); Server.ClearError(); string path = Request.Path; Context.RewritePath(string.Format("~/Errors/Http{0}", code), false); IHttpHandler httpHandler = new MvcHttpHandler(); httpHandler.ProcessRequest(Context); Context.RewritePath(path, false); }
這個方法中，我們也可以得到異常信息，記錄日誌或是郵件通知，
同樣可以根據錯誤碼進行相應的跳轉錯誤頁面。
也可以在當前錯誤頁面中添加額外的信息。
很是強大。
如果沒有寫這個方法，則利用框架封裝的默認方法。當在web.config中配置了customError節點時，便是這個方法來幫忙處理。
或許還有更多更好的方式。望指導指導，我想學習學習。
2017-11-19,望技術有成後能回來看見自己的腳步。
ASP.NET MVC下自定義錯誤頁和展示錯誤頁的幾種方式