是否存在适合使用空 catch 块的情况？

Question

可能的重复：
为什么空 catch 块不是一个好主意？
是否有任何正当理由忽略捕获的异常

你知道在什么情况下空 catch 块并不是绝对的邪恶吗？

try
{
    ...
    // What and When?
    ...
}
catch { }

Answer 1

这方面有很多问题，尝试看看：

为什么空的 catch 阻止了一个坏主意？

从该帖子接受的答案：

通常空的 try-catch 是一个坏主意，因为你会默默地吞下一个错误条件，然后继续执行。有时，这可能是正确的做法，但通常这表明开发人员看到了异常，不知道该怎么办，因此使用空 catch 来解决问题。

这在编程上相当于在引擎警告灯上贴上黑色胶带。

Answer 2

我想说，您至少应该提供某种评论或记录的消息，表明您在 try {} 中放入的内容引发了异常，这就是您不执行任何操作的原因。

Answer 3

看看这个，它基本上将您可能遇到的异常类型分为四类，其中任何一类都不应该由空的 catch 块处理。

Answer 4

公理：

空的 catch 块绝对是邪恶的

不要试图找到解决这个问题的方法。仅仅试图找到它们不是绝对邪恶的案例就意味着你正在浪费宝贵的大脑周期。不要试图在这里找到模式，想着“嗯，我应该在这里放置一个空的 catch 块吗？”

如果您在某人的代码中偶然发现了一个空的 catch 块，那么您就偶然发现了技术债务。修复它。即使只是在空的 catch 块中添加一条日志记录语句，您也会让这个世界变得更美好。

Answer 5

我将它用于一些自写的库，其中我需要某种 bool TrySomething(out object) 函数或 object TrySomething() ，其中底层调用不提供任何其他机制除外。在本例中，我使用空的 catch 块并返回 false 或 null （取决于函数签名）。

证明空 catch 块的示例

public bool TrySomething(out object destination)
{
    try
    {
        destination = DoSomething();
        return true;
    }
    catch
    {}

    return false;
}