所有关于异常的信息:做什么以及在哪里记录?

首先,如果你听到这个词 从不 你的耳朵应该振作起来。。。这就是为什么它们被称为“最佳实践”,而不是“你必须遵守的一成不变的规则…”

Exception Handling Best Practices Guide

还有很多其他的。。。

它实际上可以归结为作为开发人员的您、您的团队标准、您的客户等等。您希望应用程序做什么?

问题1: 如果引发异常,是否希望应用程序能够继续?然后我会“吞下”这个例外。

问题2 :将特定异常记录到事件日志中有什么好处吗?或者它只会用无用的信息将其膨胀,您可能希望在开发和测试期间将每个异常写入日志,并获得详细的信息,然后在生产中优化它。。。我希望我已经回答了你的问题,即使没有一个通用的问题。。。

我想说你应该有一些一般的指导方针,如果你有更多的指导方针的话 具体情况 然后,这将是一个很好的时间重新张贴到这个网站,并获得一些反馈的人,尝试了不同的路线,可以发言的优点和缺点。

这个 Code Analysis Team Blog 这是一个开始讨论这个话题的好地方。也看看

Martin Fowler - Fail Fast

MSDN on Exception Handling

Checked vs Unchecked Exceptions

你问题的第二部分真的取决于。在许多需要中央异常报告的应用程序中,写入事件日志是一个好主意。在很多其他情况下,这样做是浪费时间的,你必须根据自己的判断。

第一部分

通常,您不希望在catch块中有异常生成行为。

try
{
   ExceptionThrowingMethod();
}
Catch(Exception ex)
{
   //Log It
   //Try Again
   ExceptionThrowingMethod();
}

挡块内 . 一般来说,你的挡块应该

2. 确定当前状态是否可恢复。(是否设置了正确的变量或为空?是否在关键函数期间或两者之间中断?)

捕获块用于错误恢复,不用于常规执行。因此,即使FileNotFound是一种例外情况,也会提示用户尝试查找他们的文件 ,因此它应该在自己的try-catch(或循环回初始捕获)中发生。

一般来说,我更喜欢将日志写入它们自己的目录,因为这样我可以确切地知道它们在哪里,而且我还知道日志中的所有内容都是相关的。如果应用程序是一个关键应用程序(即需要运行一个框架的服务才能工作),那么您可以考虑将日志记录到事件查看器。还有“人人都赢”的登录方法。您可以在程序目录中有完整的日志,并将任何严重错误记录到事件查看器中。

下面是一些异常处理的最佳实践。

Best practices for exception management in Java or C#

this 为了回答我问题的第二部分,进一步的研究表明,将异常记录到事件日志中并不是一种神秘而黑暗的做法。谢谢大家的帮助。