【发布时间】：2011-08-14 08:08:30
【问题描述】：
try
{
CallMethod()
}
catch { }
根据我的经验，我通常不会这样做。
但是，如果我有一个功能说，它使用了一个偶尔会失败的第 3 方 COM 程序集，并且它实际上并不足以记录它，因为无论如何我会在几秒钟内再次调用它，可以吗？这样做？
如果没有，我还有什么选择？
【问题讨论】：
标签： c# coding-style try-catch
【发布时间】：2011-08-14 08:08:30
【问题描述】：
当然有，但应该非常罕见。
在这些情况下，您的最佳做法是在 catch 块中留下注释，以确保它是故意留空的。
【讨论】：
-
+1 用于在异常块中留下评论，让人们意识到您故意忽略异常是有原因的。
-
因为我已经看过几次了，理想情况下，它不是写着
// do nothing...的评论...说明为什么你应该什么都不做...
不应使用如图所示的空 catch 块。
例如，您问题中的代码还会捕获 OutOfMemoryException、StackOverflowException、ExecutionEngineException、AccessViolationException 和 ThreadAbortException（尽管后者将在 catch 块的末尾重新抛出）。它甚至会捕获不是从 System.Exception 派生的对象（很少见，但在托管 C++ 和 JavaScript 中可能......在 CLR 中，任何对象都可以被“抛出”，但 C# 将您限制为 Exception 派生类型）。
如果在您的示例中，您使用的是偶尔失败的第 3 方 COM 对象，并且您不关心这些失败，则应改为捕获 (COMException) {}，以便其他更严重的失败“冒泡” ' 并且可以记录和/或修复。
只捕获那些您可以实际处理的异常很重要（在这种情况下，您明确选择对 CallMethod() 产生的异常不做任何事情，我同意应该添加注释来表明这一点设计决定）。通过遵循该指南，您可以防止代码或运行时环境中的其他错误和问题被忽视。
【讨论】：
-
谢谢，我喜欢这个答案。作为补充说明，对于您无法访问或控制的第三方托管库，您有什么建议？
-
实际上 OutOfMemoryException、AccessViolationException 等异常并没有被 try..catch 处理，因为它们意味着损坏的状态。阅读更多：stackoverflow.com/questions/3469368/…
我至少会在 catch 块中使用“警告”或更低级别记录事件，这样您就可以随时启用日志记录，并在需要时查看发生了什么。
【讨论】：
-
说，你的 COM 服务每次都因为某种未知的原因而开始失败，将来能够启用日志记录并检查异常不是很有用吗？
-
我想过记录它，但说实话，它可能有 10% 的时间会失败。我觉得记录它只会用大量无用的条目压倒日志。我想也许我会在那里放一个计数器，如果它连续失败 100 次之类的，我会把它记录为问题......
-
是的。我会更进一步，在“FINE”等低级别记录每个异常，并在“ERROR”或“WARNING”级别记录“连续 100 次”事件。然后在生产中禁用“FINE”级别。猜猜我遇到了期望异常疯狂的麻烦。
通常，您希望设计代码以某种方式处理错误。
也就是说，如果你愿意默默承受失败的后果，那就继续吧。
【讨论】：
您的第三方组件出现故障。它是如何失败的？它是否以始终如一的可预测方式（虽然时间不稳定）失败？你有TakingABreakException吗？如果是这样，捕捉可预测的异常，随心所欲地处理它，记录它等等，然后让其他一切都冒出来。
不要抓住一切，如果你能抓住一个你知道不时发生的事情。 现在可能破坏的可能不是第三方组件，或者它可能由于您可能使用过的输入而表现不佳。这些东西不应该被吞下。
【讨论】：
-
问题在于，在任何情况下，我都不希望这个程序集失败而不会真正影响我的应用程序的其余部分。如果我处理 TakeABreakException，如果有另一种我没有处理的异常，如果我让它浮出水面，我会收到一条不需要的错误消息。
-
在任何情况下永远？然后你记录下来。但我宁愿希望这些失败虽然无法预防，但对它们有可预测的特征。但与往常一样，这是您的申请，我们只是坐在椅子上的四分卫，试图为您和其他有类似问题的人提供明智的建议。
-
谢谢，是的，情况很奇怪。 COM 程序集依赖于网络资源 (AD)。哦，也许土星和木星的轨道要对齐。我也许可以捕捉到一些场景，但没有足够的信心说我已经捕捉到了所有的可能性
我相信捕获异常总是一个好主意，尤其是最具体的异常，如果你知道它是什么的话。我遇到了无数从未被捕获的错误，因为代码直接通过捕获，因为它是空的，或者有人在那里放了一个返回。
【讨论】：