通常空的try-catch是一个坏主意，因为您正在默默地接受一个错误条件，然后继续执行。偶尔这可能是正确的做法，但通常这是一个迹象，表明开发人员看到了异常，不知道该如何处理，因此使用空捕获来消除问题。

这就相当于在引擎警示灯上贴上黑色胶带。

我相信如何处理异常取决于您正在使用的软件的哪个层:

通常，您应该只捕获您实际可以处理的异常。这意味着在捕获异常时要尽可能具体。捕获所有异常很少是一个好主意，而忽略所有异常几乎总是一个非常糟糕的主意。

我只能想到一些空catch块具有有意义的用途的实例。如果您正在捕获的任何特定异常都是通过重新尝试操作来“处理”的，则不需要在catch块中做任何事情。但是，记录发生异常的事实仍然是一个好主意。

另一个例子:CLR 2.0改变了终结器线程上未处理异常的处理方式。在2.0之前，允许流程在这种情况下存活。在当前CLR中，如果终止器线程上出现未处理的异常，进程将被终止。

Keep in mind that you should only implement a finalizer if you really need one and even then you should do a little as possible in the finalizer. But if whatever work your finalizer must do could throw an exception, you need to pick between the lesser of two evils. Do you want to shut down the application due to the unhandled exception? Or do you want to proceed in a more or less undefined state? At least in theory the latter may be the lesser of two evils in some cases. In those case the empty catch block would prevent the process from being terminated.

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

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

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

我认为完全空的catch块是一个坏主意，因为没有办法推断忽略异常是代码的预期行为。在某些情况下，接受异常并返回false或null或其他值并不一定是坏事。.net框架有许多“try”方法都是这样操作的。根据经验，如果应用程序支持日志记录，则添加注释和日志语句。

我的意思是，例如，有时你想从某个地方(webservice，数据库)获得一些额外的信息，你真的不关心你是否会得到这个信息。所以你试着获取它，如果发生了什么，没关系，我只会添加一个“catch (Exception ignored){}”，仅此而已

因此，以您的示例为例，在这种情况下这是一个坏主意，因为您捕获并忽略了所有异常。如果您只捕获einfofromirrelevance sourcenotavailable并忽略它，那是可以的，但您没有。您还忽略了ENetworkIsDown，它可能重要，也可能不重要。你忽略了enetworkcardhasmelting和efpuhasdecisidthatoneplusoneisseventeen，它们几乎肯定是重要的。

如果将空捕获块设置为只捕获(并忽略)您知道不重要的某些类型的异常，则空捕获块不是问题。在这种情况下，最好压制并默默地忽略所有异常，而不停下来先检查它们是否是预期的/正常的/不相关的，这种情况非常罕见。

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