【问题标题】:How to log exceptions in release mode如何在发布模式下记录异常
【发布时间】:2010-10-31 03:51:06
【问题描述】:

在发布模式下部署 .net 程序集时,不会启用堆栈跟踪。所以我们无法从异常中获取堆栈跟踪并将其记录到生产环境中。

为了了解生产代码中发生异常的位置并记录它,我们使用weird approach,我对此并不满意,但我想不出更好的解决方案来记录第一次发生异常的确切方法地点。

请注意,日志记录机制也用于确定错误。所以当引发 NullReferenceException 或 IndexOutOfBoundsException 时,仅获取异常类型和消息是没有帮助的,我们通常需要知道异常发生的确切位置。

你如何处理这个问题?发生异常时,您会在生产代码中记录哪些信息,以及如何通过这些信息确定问题所在?

【问题讨论】:

  • 在发布模式下启用了堆栈跟踪...是什么让您认为它不是?如果您使用可执行文件发布 PDB,您可以获取源文件和行号
  • 是的,但是您是否将 pdb 文件发送给您的客户?

标签: .net logging exception-handling


【解决方案1】:

看看 ELMAH,我自己还没有实现它,但它似乎得到了一些关注。

http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx

将 ELMAH 放入正在运行的 Web 应用程序并进行适当配置后,您无需更改任何一行代码即可获得以下便利:

  • 记录几乎所有未处理的异常。
  • 用于远程查看重新编码异常的整个日志的网页。
  • 用于远程查看任何已记录异常的完整详细信息的网页。
  • 在许多情况下,即使关闭了 customErrors 模式,您也可以查看 ASP.NET 为给定异常生成的原始黄屏死机。
  • 每个错误发生时的电子邮件通知。
  • 日志中最近 15 个错误的 RSS 提要。
  • 许多日志后备存储实现,包括内存中、Microsoft SQL Server 和社区贡献的几个。

【讨论】:

    【解决方案2】:

    我们在记录发布代码的堆栈跟踪时没有问题,但是我们总是在发布时附带 .pdb 文件。如果没有 pdb,您将始终受限于包含在程序集本身中的符号信息,这对于处于发布模式的程序集来说不会太多。

    【讨论】:

      【解决方案3】:

      我们所有的发布代码都有堆栈跟踪。我们唯一缺少的是行号,因为它们来自 .pdb。你在运行混淆器吗?

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-02-25
        • 1970-01-01
        相关资源
        最近更新 更多