在我的 asp.net 应用程序中，我通常使用 Application_Error 全局事件处理程序来记录错误并将用户重定向到用户友好的错误页面。
不过，我读过关于 ELMAH 的文章，虽然这看起来很有趣，但 Application_Error 似乎是更简单的方法。
我读过其他问题，其中包括我自己在内的人们提出了一种或另一种方法。我想知道的是，使用一个比另一个有什么显着的好处，为什么？
【问题讨论】：
Elmah 是一个很棒的项目，我们将它用于我们所有的 ASP.NET 应用程序。它不仅会为您记录未处理的错误，还会抓取用户看到的整个原始页面，其中包含很多细节。
它支持电子邮件、RSS 提要（逐项和摘要），并有一个有吸引力的控制台。
对于配置中的 3 行和一个 dll 引用，我会说这是一个灌篮。
【讨论】：
我猜 ELMAH 的主要缺点是它可能对你的需要来说太过分了。如果它记录和存储的信息比您在自己的实现中更多，那么在存储和处理中这是不必要的开销。您还需要考虑如何保护对 ELMAH 控制台的访问，因为这些异常详细信息可能包含您的应用程序的大量详细信息（这并不难，但这是您以前没有的担忧）。
另一方面，一旦您确定某些顽固的错误需要它，您自己的实现可能会增长以记录所有额外信息，并且您是否真的关心将错误所需的时间缩短几分之一秒要显示的页面？很有可能您最终会构建自己的 ELMAH 版本，所以为什么不直接使用 ELMAH 来节省时间。
我建议如果您确实想编写自己的错误日志记录而不是使用 ELMAH，那么您至少将它放在一个模块中，而不是直接放入 global.asax 中的 Application_Error 中。只需在模块的 Init 方法中订阅应用程序的错误事件，您就可以在 web.config 中的一行轻松地在另一个应用程序中重用您的错误处理代码。
我还发现通过 ASP.NET 的健康监控处理任何异常日志记录很有用。这使得在 web.config 中控制日志记录的类型和级别变得容易，并且还允许记录在 try...catch 中处理的异常，而不会到达 Application_Error。创建一个扩展 WebRequestErrorEvent 的自定义 HandledExceptionEvent 类，你可以在任何你想知道是否发生了异常的 catch 块中创建和引发这些事件，即使它已被处理。
【讨论】：