ASP.net错误处理(错误跳转页 webconfig)

使用定制错误页面
  
   虽然我们发送给用户的公用错误信息是安全的，就是说它不会威胁到应用程序的秘密，但是这样的信息并不好看。也许你希望用户永远也看不到这样的信息。相反，当处理请求的过程中，如果发生了一个为处理的错误，你希望能够显示自己的“定制错误页面”，显示出自己的品牌以及特定的错误信息。

向ASP.NET 应用程序中增加定制错误信息非常容易。首先，编写自己的 web页面，它可以是任何类型的文件：.htm，.aspx，.asp，等等。然后在应用程序的config.web文件中修改配置信息，让它指向这个文件。

举例说明，以下这个配置信息说明在发生了任何未能预定处理错误的情况下，浏览器都应该被重定向到“ErrorPage.aspx”页面：

<configuration>
<customerrors mode="remoteonly" defaultredirect="ErrorPage.aspx" />
</configuration>

<customerrors>标记中的“defaultredirect”属性定义了在发生错误的情况下，用户将被重定向到的“默认”页面。或者，也可以根据响应的http代码状态，重定向到其它的页面来覆盖这个默认值。例如：重定向到一个特殊的“未找到文件”错误页面、“非法访问”错误页面、“服务器冲突”错误页面等等。

举例说明，以下的配置信息覆盖3个特定的http 状态代码，所有其它错误都返回到一个默认页面：

<customerrors defaultredirect="http://anotherhost/error.aspx" mode="remoteonly">
<error statuscode="500" redirect="http:/anotherhost/pages/callsupport.html" />
<error statuscode="404" redirect="http:/anotherhost/pages/adminmessage.html" />
<error statuscode="403" redirect="http:/anotherhost/pages/noaccess.html" />
</customerrors>

在定制错误页面上有一件事我们已经遇到过，那就是虽然它们对于已经完成的情况非常有用，然而在开发过程中却非常难以对付。因为你预想到在开发过程中会有bug，并且当你发现的时候，真的希望看到实际的错误信息跟踪。为了解决这个问题，<customerrors>标记支持一个有3个值的“mode”属性：

“on”：意思是总是发出定制错误页面；

“off”：意思是从不发出定制错误页面（你总是看到原始的错误信息）；

“remoteonly”：意思是只有当远程浏览器点击站点时才发出定制错误页面（而在实际机器上点击站点的开发人员看到的是详细的错误信息）。

二,在Global.asax文件中添加应用出错代码，写入系统日志文件
protected void Application_Error(Object sender, EventArgs e)
{
Exception LastError = Server.GetLastError();
String ErrMessage = LastError.ToString();

String LogName = "MyLog";
String Message = "Url " + Request.Path + " Error: " + ErrMessage;

// Create Event Log if It Doesn't Exist

if (!EventLog.SourceExists(LogName))
{
EventLog.CreateEventSource(LogName, LogName);
}
EventLog Log = new EventLog();
Log.Source = LogName;
//These are the five options that will display a different icon.
Log.WriteEntry(Message, EventLogEntryType.Information, 1);
Log.WriteEntry(Message, EventLogEntryType.Error, 2);
Log.WriteEntry(Message, EventLogEntryType.Warning, 3);
Log.WriteEntry(Message, EventLogEntryType.SuccessAudit, 4);
Log.WriteEntry(Message, EventLogEntryType.FailureAudit, 5);

}