集中式ASP.NET错误处理：与Application_Error相对.可以同时使用两者吗？

2023年11月14日 199次阅读

目前,我们正在通过global.asax.vb中的Application_Error进行错误处理：

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    OurLibrary.HandleError(Me)
End Sub

然后HandleError将错误记录到数据库中,向用户显示信息性消息,并根据发生的异常类型返回正确的状态代码(404或500)：

Public Shared Sub HandleError(httpApp As HttpApplication)
    ''# do some logging
    ...

    ''# show some details about the error and information about how to contact us
    httpApp.Response.Write(...)

    httpApp.Response.StatusCode = 404 or 500
    httpApp.Server.ClearError()
End Sub

Server.ClearError是必需的,因为否则默认的ASP.NET错误处理会启动并显示用户 – 具体取决于< customErrors>的当前状态. – “黄色死亡屏幕”或关于如何< customErrors>的信息消息可以关掉.

使用ClearError的缺点是我不能再使用< customErrors>覆盖错误处理行为 – 这在最近的ASP.NET vulnerability期间带来了相当多的麻烦,其中推荐的解决方法是使用< customErrors>完成的.

我知道我只能使用customErrors并在defaultRedirect属性引用的页面中显示用户的信息,但这需要我将此错误页面添加到每个单独的Web项目中(而不是将所有内容集中在一个库函数中) ).

是否可以在Application_Error中进行常规错误处理,但仍允许它被< customErrors>？覆盖？这是最佳实践还是我做了一些根本错误的事情？

PS：我们的许多应用程序都托管在我们客户的服务器上(而不是我们自己的),因此“将所有信息都放在应用程序日志中并向用户显示”并不是一个真正的选择.

解决方案：将httpApp.Server.ClearError()替换为

If Not HttpContext.Current.IsCustomErrorEnabled Then httpApp.Server.ClearError()

最佳答案 在大多数情况下,我个人认为人们选择的方法类似于你正在做的事情.以自己的方式做事有很多好处.

>错误不再写入窗口中的应用程序日志,这有助于确保最大限度地减少杂乱/开销.
>正如您所提到的,您有一个易于部署的方法来添加日志记录.

我注意到人们过去常常使用过许多解决方法,但最常见的是让用户让他们的自定义处理程序知道CustomErrors设置.因此,基本上您的代码会查看它要发送的响应代码,然后根据自定义错误执行操作.这真的是两全其美.

点赞