ASP.NET 3.5核心编程学习笔记（8）：错误处理、页面跟踪

页面错误的处理

　　ASP.NET提供了两级全局异常拦截点，分别位于页面级与应用程序级。

　　基类Page暴露了一个Error事件，我们可在页面中重写它，捕获页面执行期间引发的未处理异常。

　　HttpApplication类中也有Error事件，用于捕获整个应用程序中抛出的所有未处理异常。

页面级错误处理

　　为捕获特定页面的未处理异常，我们需要定义Error事件的处理程序，如下所示：

protected void Page_Error( object sender, EventArgs e)
{
Exception ex = server.GetLastError();

if (ex is NotImplementedException)
Server.Transfer( " /errorpages/notimplementexception.aspx " );
else
Server.Transfer( " /errorpages/apperror.aspx " );

Server.ClearError();
}

　　通过Server对象的GetLastError方法，我们能获取被引发的异常。如果通过Server.Transfer来传输控件，异常信息会被保留，错误页面可调用GetLastError，并显示更详细的信息。最后，一旦所有异常处理执行完毕，应调用ClearError清除错误。

　　在显示错误消息时，注意不要公开敏感信息以防止恶意用户利用它们对系统发起攻击。我们可以使页面更灵活些，让它判断用户是否位于本地，是否选用自定义标头，并显示有助于错误诊断的详细信息：

if (Request.UserHostAddress == " 127.0.0.1 " )
{
......
}

　　可使用Request.Headers集合来检查自定义的标头信息。为添加自定义标头，打到应用程序Internet信息服务（IIS）虚拟目录的属性，然后单击HTTP标头选项卡即可。

全局错误处理

　　添加global.asax文件到程序中，并在预定义的Application_Error方法中编写代码：

void Application_Error( object sender, EventArgs e)
{
......
}

　　我们可在该事件处理程序中做一些有意义的事，比如向管理员发送电子邮件或写入Windows事件日志。

错误与页面映射

　　当未处理异常抵达调用堆栈的末端时，ASP.NET会生成一个默认页面，显示一个黄屏。通过应用程序web.config文件中的<customErrors>区段，开发者可以对ASP.NET这个功能充分进行定制：

< configuration >
< system.web >
......
< customErrors mode = " RemoteOnly " defaultRedirect = " /GerericError.aspx " />
</ system.web >
</ configuration >

　　不论错误是什么，ASP.NET都会将用户重定向到GenericError.aspx页面。

　　除将用户重定向到通用的错误页面上，ASP.NET还使我们能够针对发生的不同HTTP错误显示相应的自定义页面，如下示例：

< configuration >
< system.web >
< customErrors mode = " On " defaultRedirect = " /GenericError.aspx " >
< error statusCode = " 404 " redirect = " /ErrorPages/Error404.aspx " />
< error statusCode = " 500 " redirect = " /ErrorPages/Error500.aspx " />
</ customErrors >
</ system.web >
</ configuration >

　　当底层ASP.NET调用错误页面时，引起错误的页面的URL会被传入其中，示例：  

public partial class Error404 : System.Web.UI.Page
{
protected void Page_Load( object sender, EventArgs e)
{
object o = Request.QueryString[ " AspxErrorPath " ];

if (o != null )
{
......
}
}
}

　　如果应用程序级错误处理程序、页面级处理程序和各种重定向同时存在，会优先考虑哪一种？应用程序级处理程序优先于其他处理程序。页面级代码会在所有代码处理完HTTP 500内部错误后运行。

ASP.NET跟踪

　　.NET带有功能丰富的程序跟踪工具集。尤其是Systems.Diagnostics命名空间中定义的Trace和Debug类。这两个类基本相同，都建立在“监听程序”模块基础上。监听程序作为一种驱动程序，会收集跟踪的消息，并将这些消息存储在特定的介质中。

页面跟踪的启用方法

　　我们可在应用程序的web.config文件中切换trace属性的开关状态：

< configuration >
< system.web >
< trace enabled = " true " pageOutput = " true " />
</ system.web >
</ configuration >

　　pageOutput属性用于提示是否将输出显示在页面中。如果pageOutput被设置为false，跟踪输出会被自动发送到ASP.NET的跟踪工具（trace.axd）中。

　　@Page指令中的trace属性默认为false，如果为true，跟踪信息就会被显示在页面的底部。

　　@Page指令还提供了TraceMode属性，使我们能够选择被显示数据的排序方式。可能的值为SotrByCategory和SortByTime，默认值为SortByTIme。

　　Page类提供了两个属性TraceModeValue和TraceEnabled分别对应与上述的@Page指令属性。

　　Page类与跟踪有关的第三个属性是Trace，它返回TraceContext类的实例。通过TraceContext类的方法，可向ASP.NET页面中追加跟踪日志。在HTTP请求建立时，便会创建该类的实例。跟踪对象通过HttpContext类的Trace属性暴露出来。

　　TraceContext类的IsEnabled属性表示跟踪是否开启，TraceMode属性表示跟踪记录在页面中的排列模式。

　　TraceContext类的Write和Warn方法输出消息，这两个方法基本相同，唯一差别在于Warn输出消息为红色。

　　使用Write方法与Warn方法传送的文本都会显示在HTML页面中，但并未对HTML格式标签进行任何处理。该文本是以纯文本的形式写入的。如果要获得加粗字符，直接对跟踪消息的子字符串添加<b>和</b>即可。

　　如果外部类要向当前HTTP请求的跟踪日志中发送文本，则可这样表达：

　　System.Web.HttpContext.Current.Trace.Write(category, msg);

　　一旦应用程序跟踪功能被启用，每个页面请求都会将特定页面的跟踪信息转给查看器。我们可在应用程序根目录下请求trace.axd打开跟踪查看器（如：http://localhost:1105/Core35/Trace.axd）。

　　跟踪查看器能够缓存的请求数由requestLimit属性限定（默认值为10）。示例：　　

< system.web >
< trace enable = " true " requestList = " 20 " />
</ system.web >

　　跟踪查看器会自动跟踪所有请求，并缓存每个请求的完整跟踪信息。当请求数达到上限后，其他请求便不会被缓存，除非当前的跟踪信息被手动删除。

转载于:https://www.cnblogs.com/free722/archive/2011/04/16/2017624.html