我被赋予了重写我们的异常处理系统的惊险任务。虽然我会说从应用程序范围来看处理异常并不是我们想要的,但是当我们的团队因为我们需要推出门的大量工作而人手不足时通常是不可避免的,所以请不要燃烧这里的异常处理全球化解决方案:)
我已经很好地了解了常见的解决方案。目前,我们将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足以在我们的特定场景中使用它 - 直到会话数据特定的事件对我们来说太危险了。
答案 0 :(得分:6)
使用模块具有易于移除的优点,您需要做的就是将其从< httpModules>中删除。在你的配置中。
就您的数据而言,请尝试使用Server.Transfer或Server.RewritePath - 这将保留所有当前数据(包括上次服务器错误)。
如果由于某种原因它清除了上一个错误,您可以在传输/重写之前将错误保存到HttpContext.Items,然后再检索它。
编辑:为了响应您的编辑,IHttpModule会附加到其IHttpModule.Init实施中的任何相应事件中。
答案 1 :(得分:1)
HttpModule
基本上与Global.asax
做同样的事情。它被设计为一个更可重用且独立的事件处理模块。