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