在网站运行中，错误是不可避免的,错误页的产生也是不可缺少的。
这几天看了博友的很多文章，自己想总结下我从中学到的和实际中配置的。
首先，需要知道产生错误页的来源，一种是我们的.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职责中。
namespace SAssassin.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,望技术有成后能回来看见自己的脚步。