关于例外情况：做什么以及在哪里登录？

Question

我的问题实际上分为两部分，因此标题含糊不清。

第一部分

据我所知，你永远不应该吞下一个例外。甚至没有记录它而忘记了。在一般情况下，我尝试解决异常并重试代码 - 例如，假设我得到一个FileNotFound异常。

我提示用户检查文件是否存在并重试，提供另一个文件选择器对话框并希望最好。如果未能尝试解决问题，我最终会通知用户并记录异常。我被告知在catch块中这不是正确的事情，所以我是通过尝试解决问题来做到的吗？

我想不出还有什么我应该做的。我怀疑我被喂错了信息 - 我是一个可以自欺欺人的灵魂。

第二部分

在我的程序目录中创建一个日志以记录异常我认为很好，但我再次被告知应该将异常写入windows eventlog。它是否正确？在什么情况下你应该写入事件日志？

愚蠢的问题需要愚蠢的答案。

编辑： 除了一般模糊的领域之外，这个问题没有任何背景。我和我的朋友在特定情况下正在做正确的事情。“

Answer 1

首先，如果您听到从不这个词，您的耳朵应该振作起来...这就是为什么它们被称为“最佳实践”而不是“您必须遵循的石头规则” 。“

这是微软的Exception Handling Best Practices Guide

还有很多其他人......

作为开发人员，团队标准，客户等，这真的归结为您。您希望应用程序做什么？

问题1：您是否希望应用程序在抛出异常时能够继续？然后我会“吞下”异常。

问题2 ：将特定异常记录到事件日志中是否有好处，或者它是否会使用无用的信息使其膨胀，您可能希望在开发期间将每个异常写入日志并且测试并且有详细的信息，然后在生产中简化它...我希望我已经回答了你的问题，即使它确实没有通用的...

我会说你应该有一些一般的指导方针，然后如果你有更多具体情况那么现在是重新发布到这个网站并从尝试过的人那里获得一些反馈的好时机不同的路线，可以说利弊。

Answer 2

Code Analysis Team Blog是开始讨论此主题的好地方。还看看

Martin Fowler - Fail Fast

MSDN on Exception Handling

Checked vs Unchecked Exceptions

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

Answer 3

第一部分

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

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

显然，第二个例外将是未被捕获的，并且您通常不希望在catch-block 中嵌套。  通常你的catch块应该

1. 记录错误。总是。即使您将其设置为最低日志记录级别，也从不读取这些日志。
2. 确定您当前的状态是否可恢复。 （正确的变量是设置还是为空？它是否在关键函数期间或它们之间中断？）
3. 如果你可以恢复，设置一些指示'try-again'的变量，并允许执行流出catch块。如果无法恢复，请尝试添加一些上下文，然后重新抛出错误。

Catch块用于错误恢复，而不是用于常规执行。因此，即使通过FileNotFound是一种特殊情况，提示用户尝试找到他们的文件而不是，因此它应该在自己的try-catch中发生（或循环回到初始的）。

第二部分

通常，我更喜欢将日志写入自己的目录，因为这样我就知道它们到底在哪里，而且我也知道日志中的所有内容都是相关的。如果您的应用程序是关键应用程序（I.E.需要为框架运行而运行的服务），那么您可以考虑登录到事件查看器。还有每个人都赢得了记录到两者的方法。您可以在程序目录中拥有完整的日志，并将任何严重错误记录到事件查看器中。

我不知道你给登录到事件查看器的原因是什么，我不知道这是否是一个好建议。

Answer 4

以下是一些异常处理的最佳做法。

Best practices for exception management in Java or C#

Answer 5

我发现this回答了我的问题的第二部分，从一些进一步的研究看来，记录事件日志的异常并不是一个神秘而黑暗的做法。感谢大家的帮助。