小編給大家分享一下ASP.NET MVC下自定義錯誤頁和展示錯誤頁的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

十載的薛城網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整薛城建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“薛城網(wǎng)站設(shè)計(jì)”,“薛城網(wǎng)站推廣”以來，每個客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

在網(wǎng)站運(yùn)行中，錯誤是不可避免的,錯誤頁的產(chǎn)生也是不可缺少的。

這幾天看了博友的很多文章，自己想總結(jié)下我從中學(xué)到的和實(shí)際中配置的。

首先，需要知道產(chǎn)生錯誤頁的來源，一種是我們的.NET平臺拋出的，一種是網(wǎng)站所依賴的宿主拋出的，一般來講我們所依賴的宿主就是IIS了。

IIS中的錯誤頁入口：

其中的錯誤碼想必并不陌生

這里是在服務(wù)器上找不到所需資源時拋出的錯誤頁,在這里可以設(shè)置需要展示的錯誤頁面，只需將預(yù)定的錯誤頁面加入服務(wù)器中，然后在指定狀態(tài)碼下配置路徑即可。

這是請求在IIS中時，還未完全進(jìn)入到asp.net mvc中，這里需要理解什么是未完全進(jìn)入，IIS7+的版本中,不依賴于請求路徑末尾的標(biāo)識信息，利用mvc中的urlRoutingModule進(jìn)行處理，在我們配置mvc的路由時,首先的第一條：

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

便是隔離非mvc內(nèi)部的使用文件，如果請求的只是服務(wù)器上的文件，那么路由便會在這里進(jìn)行過濾，使之不匹配具體路由信息。

也就只是和mvc打了個招呼 然后就走了,沒有進(jìn)入mvc中搞事情。

第二種是,進(jìn)入了asp.net mvc的管轄范圍，然后在其中出錯了，便是跳到我們在程序中配置的錯誤頁了。

首先講講我從博友那里學(xué)到的、看到的幾種方式。

第一種是在web.config中通過customError配置。

但是這種方式不怎么令人接受，太過于簡單，沒有一點(diǎn)異常信息，并且有時候還不能起效果，我不太喜歡這種方式。

這種是用框架封裝好的，利用的是將要說的第三種的強(qiáng)大方式實(shí)現(xiàn)的,當(dāng)有異常發(fā)生又沒得捕獲時，最終利用的第三種方式自動實(shí)現(xiàn)。

第二種是利用HandlerErrorAttribute 特性，利用AOP的方式，當(dāng)有異常出現(xiàn)時，便會進(jìn)入具體實(shí)現(xiàn)了這個特性的，且被注冊了的ExceptionAttribute職責(zé)中。

namespace SAssassin.Web.Core.Filter
{
  /// 

  /// 異常處理之日志記載采用消息隊(duì)列方式
  /// 
  public class MyExceptionAttribute : HandleErrorAttribute
  {
    public static Queue ExceptionQueue = new Queue();
    public override void OnException(ExceptionContext filterContext)
    {
      ExceptionQueue.Enqueue(filterContext.Exception);
      filterContext.HttpContext.Response.Redirect("~/ErrorPage/CustomErrorPage");
      base.OnException(filterContext);
    }
  }
}

在這里，我可以得到異常信息，也可以解析具體的異常報(bào)錯原因，比如404，500...  可以通過這種形勢，將其轉(zhuǎn)移到不同的自定義錯誤頁面上，此處我增加了一個控制器

CustomErrorPageController,專門用來存放錯誤頁面，原有的Shared下的Error.cshtml錯誤頁面也仍然存在著。

我比較喜歡這種方式，一來可以看到異常信息，而來可以設(shè)計(jì)需要跳轉(zhuǎn)的錯誤頁面。

第三種方式也是最強(qiáng)大的、俗稱"最后一道防線"，從全局層面去捕捉異常的Application_Error

當(dāng)網(wǎng)站初次啟動時，會執(zhí)行一個特殊的動作,Application_start 首先執(zhí)行，也只初始化一次。這個也是Application 中的事件。

//
    // 摘要:
    //   ASP.NET 將 HTTP 標(biāo)頭發(fā)送到客戶端之前發(fā)生。
    public event EventHandler PreSendRequestHeaders;
    //
    // 摘要:
    //   在選擇該處理程序?qū)φ埱笞鞒鲰憫?yīng)時發(fā)生。
    public event EventHandler MapRequestHandler;
    //
    // 摘要:
    //   釋放應(yīng)用程序時發(fā)生。
    public event EventHandler Disposed;
    //
    // 摘要:
    //   作為執(zhí)行的 HTTP 管道鏈中的第一個事件發(fā)生，當(dāng) ASP.NET 的請求做出響應(yīng)。
    public event EventHandler BeginRequest;
    //
    // 摘要:
    //   當(dāng)安全模塊已建立的用戶標(biāo)識時出現(xiàn)。
    public event EventHandler AuthenticateRequest;
    //
    // 摘要:
    //   當(dāng)安全模塊已建立的用戶標(biāo)識時出現(xiàn)。
    public event EventHandler PostAuthenticateRequest;
    //
    // 摘要:
    //   安全模塊已驗(yàn)證用戶身份驗(yàn)證時發(fā)生。
    public event EventHandler AuthorizeRequest;
    //
    // 摘要:
    //   當(dāng)前請求的用戶已被授權(quán)時發(fā)生。
    public event EventHandler PostAuthorizeRequest;
    //
    // 摘要:
    //   當(dāng) ASP.NET 完成授權(quán)事件以便從緩存中，跳過的事件處理程序 （例如，一個頁面或 XML Web 服務(wù)） 執(zhí)行的請求提供服務(wù)的緩存模塊時發(fā)生。
    public event EventHandler ResolveRequestCache;
    //
    // 摘要:
    //   ASP.NET 將繞過當(dāng)前事件處理程序的執(zhí)行，并允許緩存模塊以處理從緩存請求時發(fā)生。
    public event EventHandler PostResolveRequestCache;
    //
    // 摘要:
    //   ASP.NET 將內(nèi)容發(fā)送到客戶端之前發(fā)生。
    public event EventHandler PreSendRequestContent;
    //
    // 摘要:
    //   當(dāng) ASP.NET 已映射到相應(yīng)的事件處理程序的當(dāng)前請求時出現(xiàn)。
    public event EventHandler PostMapRequestHandler;
    //
    // 摘要:
    //   當(dāng) ASP.NET 已完成處理的事件處理程序時發(fā)生 System.Web.HttpApplication.LogRequest 事件。
    public event EventHandler PostLogRequest;
    //
    // 摘要:
    //   已釋放與請求相關(guān)聯(lián)的托管的對象時發(fā)生。
    public event EventHandler RequestCompleted;
    //
    // 摘要:
    //   獲取與當(dāng)前的請求相關(guān)聯(lián)的請求狀態(tài) （例如，會話狀態(tài)） 時發(fā)生。
    public event EventHandler PostAcquireRequestState;
    //
    // 摘要:
    //   ASP.NET 開始執(zhí)行事件處理程序 （例如，一個頁面或 XML Web 服務(wù)） 之前發(fā)生。
    public event EventHandler PreRequestHandlerExecute;
    //
    // 摘要:
    //   當(dāng) ASP.NET 事件處理程序 （例如，一個頁面或 XML Web 服務(wù)） 完成執(zhí)行時發(fā)生。
    public event EventHandler PostRequestHandlerExecute;
    //
    // 摘要:
    //   ASP.NET 完成執(zhí)行所有請求事件處理程序后發(fā)生。 此事件會導(dǎo)致狀態(tài)模塊保存當(dāng)前的狀態(tài)數(shù)據(jù)。
    public event EventHandler ReleaseRequestState;
    //
    // 摘要:
    //   當(dāng) ASP.NET 已完成執(zhí)行所有請求事件處理程序和存儲數(shù)據(jù)的請求狀態(tài)時發(fā)生。
    public event EventHandler PostReleaseRequestState;
    //
    // 摘要:
    //   當(dāng) ASP.NET 完成執(zhí)行事件處理程序，以便讓緩存模塊存儲將用于為從緩存中的后續(xù)請求提供服務(wù)的響應(yīng)時發(fā)生。
    public event EventHandler UpdateRequestCache;
    //
    // 摘要:
    //   當(dāng) ASP.NET 完成更新的緩存模塊和存儲用于為從緩存中的后續(xù)請求提供服務(wù)的響應(yīng)時發(fā)生。
    public event EventHandler PostUpdateRequestCache;
    //
    // 摘要:
    //   ASP.NET 執(zhí)行當(dāng)前請求的任何日志記錄之前發(fā)生。
    public event EventHandler LogRequest;
    //
    // 摘要:
    //   當(dāng) ASP.NET 獲取與當(dāng)前的請求相關(guān)聯(lián)的當(dāng)前狀態(tài) （例如，會話狀態(tài)）。
    public event EventHandler AcquireRequestState;
    //
    // 摘要:
    //   作為執(zhí)行的 HTTP 管道鏈中的最后一個事件發(fā)生，當(dāng) ASP.NET 的請求做出響應(yīng)。
    public event EventHandler EndRequest;
    //
    // 摘要:
    //   當(dāng)引發(fā)未處理的異常時發(fā)生。
    public event EventHandler Error;

看到最后一個事件，當(dāng)引發(fā)未處理的異常時發(fā)生，便是最后一道防線登場了。如果沒有用aop的方式捕捉異常，那么就是Application _Error登場了。

在Global.asax中我們可以寫上這個方法

/// 

    /// 可以完成全局異常處理
    /// 
    /// 
    /// 
    protected void Application_Error(object sender, EventArgs e)
    {
      // 在出現(xiàn)未處理的錯誤時運(yùn)行的代碼
      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);
    }

這個方法中，我們也可以得到異常信息，記錄日志或是郵件通知，

同樣可以根據(jù)錯誤碼進(jìn)行相應(yīng)的跳轉(zhuǎn)錯誤頁面。

也可以在當(dāng)前錯誤頁面中添加額外的信息。

很是強(qiáng)大。

如果沒有寫這個方法，則利用框架封裝的默認(rèn)方法。當(dāng)在web.config中配置了customError節(jié)點(diǎn)時，便是這個方法來幫忙處理。

以上是“ASP.NET MVC下自定義錯誤頁和展示錯誤頁的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

標(biāo)題名稱：ASP.NETMVC下自定義錯誤頁和展示錯誤頁的示例分析-創(chuàng)新互聯(lián)
URL網(wǎng)址：http://weahome.cn/article/dsjiec.html