Question

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

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()

Answer 1

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

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

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

集中式ASP.NET错误处理：<customerrors>与Application_Error。是否可以同时使用？</customerrors>

1 个答案: