C# 所有关于异常的信息：做什么以及在哪里记录？

我的问题实际上分为两部分，因此标题模棱两可

---

第一部分

就我所知，你永远不应该接受例外情况。甚至都没有记录下来，也没有忘记。在一般情况下，我会尝试解决一个异常并重试代码——例如，假设我得到一个FileNotFound异常

我会提示用户检查文件是否存在，然后再试一次，提供另一个文件选择器对话框，希望得到最好的结果。尝试解决问题失败后，我通知用户并记录异常。有人告诉我，这不是在捕捉块中要做的正确事情，那么我通过尝试解决问题来做对了吗

我想不出我还能做什么。我怀疑我被误导了——我是一个容易上当受骗的人

第二部分

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

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

编辑：

---

除了一个一般的模糊领域外，这个问题没有上下文。我的朋友和我一直在喋喋不休地谈论在特定情况下应该做的正确的事情。

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

---

第一部分

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

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

显然，第二个异常是未捕获的，您通常不希望在catch块中嵌套try-catch。 一般来说，你的挡块应该

记录错误。总是。即使您将其设置为最低日志记录级别，并且从不读取这些日志

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

如果可以恢复，请设置一些指示“重试”的变量，并允许执行从catch块流出。如果无法恢复，请尝试添加一些上下文，然后重新抛出错误

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

第二部分

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

---

我不知道你被要求登录事件查看器的原因，我不知道这是否是一个好建议。

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

这是微软的

还有很多其他的

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

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

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

我想说的是，你应该有一些一般性的指导方针，如果你有更多的具体情况，那么这将是一个很好的时间重新发布到这个网站，并从尝试过不同路线的人那里获得一些反馈，他们可以谈论优缺点

这是一个很好的开始这个话题的地方。也看看

---

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

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

很抱歉，我不相信这能回答我的问题。你问的是愚蠢的答案：）。。。我同意，它并没有完全回答您的问题，但它确实解决了异常处理的最佳实践，这是您在研究如何处理代码中的异常时可能需要研究的问题。是的，我会在这方面给您评分。我从这个链接中学到了一些新东西，但仍然没有找到答案。从不浪费！这只是一场毫无背景的讨论。我和我的朋友得出的结论是，这可能是一个特定于上下文的案例，但最好在事件日志中写上“这就是它存在的原因”。正如我前面提到的，这主要是我和一位朋友之间的一般性对话，没有真正的结论。我可能应该在问题中添加这一点。那么，如果这只是你和你朋友之间的事，你为什么要在这里发布它：0）因为我们最终意见不一致，我想我可以向更广泛的听众提问，看看谁更接近正确（是他）