try
{
CallMethod()
}
catch { }
根据我的经验，我通常不会这样做。
但是，如果我有一个功能说，使用第三方COM组件偶尔会失败，实际上不足以记录它因为我将在几秒钟内再次调用它，是否可以这样做？
如果没有，我还有什么选择？
答案 0 :(得分：9)
当然有时候，但它们应该非常罕见。
在这些情况下，您的最佳做法是在catch区块中留下评论，以确保明确表示它有意留空。
答案 1 :(得分：7)
不应使用如图所示的空挡块。
例如，您的问题中的代码也会捕获OutOfMemoryException，StackOverflowException，ExecutionEngineException，AccessViolationException和ThreadAbortException（尽管后者将在catch块的末尾重新抛出）。它甚至会捕获不是从System.Exception派生的对象（很少见，但在托管C ++和JavaScript中可能......在CLR中，任何对象都可以'抛出'，但C＃将你限制为Exception派生类型）。
在您的示例中，如果您使用的第三方COM对象偶尔会失败并且您不关心这些失败，那么您应该捕获（COMException）{}，以便其他更严重的失败“冒出来” '并且可以记录和/或修复。
重要的是只捕获那些你可以实际做的事情（在这种情况下，你明确选择不对CallMethod（）引起的异常做任何事情，我同意应该添加一个注释来表明这一点设计决定）。通过遵循该指导，您可以防止代码或运行时环境中的其他错误和问题被忽视。
答案 2 :(得分：2)
通常，您希望设计代码以某种方式处理错误。
那就是说，如果你愿意无声地处理失败的后果，那就继续吧。
答案 3 :(得分：2)
我至少会在catch块中以“警告”或更低级别记录事件，这样您就可以始终启用日志记录，并在需要时查看正在发生的事情。
答案 4 :(得分：0)
您的第三方组件失败。它怎么会失败？它是否以一致的可预测性（虽然时间不稳定）方式失败？你有TakingABreakException吗？如果是这样，抓住可预测的异常，用它做任何事情，记录它等等，让其他一切冒出来。
如果你能抓住你不时知道的 one 事件，那么不会抓住所有内容。什么可能打破现在可能不是第三方组件，或者由于您可能使用过的输入而可能表现不佳。不应该吞下这些东西。
答案 5 :(得分：0)
我认为捕捉异常总是一个好主意，特别是如果你知道它是什么，最特别的例外。我遇到了无数的错误，这些错误从未被捕获过，因为代码直接通过了捕获，因为它被留空或有人在那里返回。