我被赋予了重写我们的异常处理系统的惊险任务.虽然我会说从应用程序范围来看处理异常并不是我们想要的,但是当我们的团队因为我们需要推出门的大量工作而人手不足时通常是不可避免的,所以请不要燃烧这里异常处理的全球化解决方案:)
我有一个很好的追捕,看看有什么常见的解决方案.目前,我们将Global.asax与Application_Error事件一起使用以执行处于会话状态的Server.GetLastError(),然后将重定向调用到另一个页面,然后检索会话数据并以人类可读的格式输出.重定向还调用一个sproc,它将仔细审核错误信息,a)通过电子邮件发送给开发人员,b)从只能由开发人员查看的网页查看.
我看到做事的新方法是使用IHttpModule接口使用App_Code中的类来做这些事情(这是我的快速实现)
Imports Microsoft.VisualBasic Public Class ErrorModule : Implements IHttpModule Public Sub Dispose() Implements System.Web.IHttpModule.Dispose ' Not used End Sub Public Sub Init(ByVal context As System.Web.HttpApplication) Implements System.Web.IHttpModule.Init AddHandler context.Error, AddressOf context_Error End Sub Public Sub context_Error(ByVal sender As Object, ByVal e As EventArgs) Dim ex As Exception = HttpContext.Current.Server.GetLastError ' do something with the error ' call the stored procedure ' redirect the user to the error page HttpContext.Current.Server.ClearError() HttpContext.Current.Response.Redirect("index.htm") End Sub End Class
我的问题是,这个解决方案比使用Global.asax事件有什么好处?此外,将数据传递到错误页面的最佳方法是什么?
编辑:上面的代码确实工作;)
编辑:另外,HttpModule如何在幕后工作?是否只是在应用程序启动时将Error事件注册到该特定函数?
更新:
经过进一步的调查,在使用IHttpModule接口时,抓住会话数据真的非常麻烦.我不认为MS已经成熟HttpModule足以在我们的特定场景中使用它 - 直到会话数据特定的事件对我们来说太危险了.
使用模块具有易于移除的优点,您需要做的就是将其从配置中的
就您的数据而言,请尝试使用Server.Transfer或Server.RewritePath - 这将保留所有当前数据(包括上次服务器错误).
如果由于某种原因它清除了最后一个错误,您可以在传输/重写之前将错误保存到HttpContext.Items,然后再检索它.
编辑:为了响应您的编辑,IHttpModule附加到其IHttpModule.Init实现中的任何适当事件.