集中式 ASP.NET 错误处理：与应用程序错误。两者都可以使用吗？

Question

目前，我们正在通过 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 错误处理将启动并且用户显示 - 取决于 的当前状态 - 要么是“死机黄屏”，要么是有关如何处理 的信息消息关闭。

使用 ClearError 的缺点是我无法再使用 来覆盖错误处理行为——这在最近的 < a href="http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx" rel="nofollow">ASP.NET 漏洞 ，其中建议的解决方法是使用 完成的。

我知道我可以使用 only customErrors 并在 defaultRedirect 属性引用的页面中显示用户的信息，但这需要我将此错误页面添加到每个 Web 项目中（而不是将所有内容都很好地集中在一个库函数中）。

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

PS：我们的许多应用程序都托管在客户的服务器上（而不是我们自己的服务器），因此“将所有信息放入应用程序日志中而不向用户显示任何内容”并不是真正的选择。

---

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

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

Answer 1

就我个人而言，大多数时候我看到人们选择与您正在做的类似的方法。按照自己的方式做事有很多好处。

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

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