我发现最令人讨厌的空catch语句是其他程序员做的。我的意思是，当您需要调试别人的代码时，任何空的catch语句都会使这种工作变得更加困难。恕我直言，catch语句应该总是显示某种错误消息——即使错误没有被处理，它至少应该检测到它(只在调试模式下启用)

因为如果抛出异常，您将永远不会看到它——默默地失败是最糟糕的选择——您将得到错误的行为，而且不知道它发生在哪里。至少在那里放一条日志消息!即使是“不可能发生”的事情!

这与“不要使用异常来控制程序流”和“只在异常情况下使用异常”是密切相关的。如果执行了这些操作，那么只有在出现问题时才会出现异常。如果出现了问题，你也不想默默地失败。在不需要处理问题的罕见异常中，您至少应该记录异常，以防异常不再是异常。比失败更糟糕的是默默的失败。

空的catch块通常被放入，因为编码器并不真正知道他们在做什么。在我的组织中，一个空的catch块必须包含一个注释，说明为什么不处理异常是一个好主意。

与此相关的是，大多数人不知道try{}块后面可以跟catch{}或finally{}，只有一个是必需的。

空捕获块表示程序员不知道如何处理异常。它们正在抑制异常可能出现的冒泡，并由另一个try块正确处理。总是尝试做一些你正在捕捉的例外。

我不会把事情延伸到说使用空catch块的人是一个糟糕的程序员，不知道他在做什么……

如果需要，我使用空捕捉块。有时我正在使用的库的程序员不知道他在做什么，甚至在没有人需要的情况下抛出异常。

例如，考虑一些http服务器库，如果服务器抛出异常，因为客户端已断开连接，index.html无法发送，我不会太在意。