只有在确实出现异常时才应该抛出异常——发生了超出正常范围的事情。一个空的catch块基本上表示“一些不好的事情正在发生，但我只是不在乎”。这是个坏主意。

如果您不想处理异常，就让它向上传播，直到它到达一些可以处理它的代码。如果没有任何东西可以处理异常，则应该关闭应用程序。

我认为如果你捕捉到一个特定的异常类型，你知道它只会因为一个特定的原因而被引发，并且你期待这个异常，并且真的不需要对它做任何事情，这是可以的。

但即使在这种情况下，也可能需要调试消息。

如果你不知道在catch block中要做什么，你可以只记录这个异常，但不要让它空着。

        try
        {
            string a = "125";
            int b = int.Parse(a);
        }
        catch (Exception ex)
        {
            Log.LogError(ex);
        }

第65项:不要忽视有效Java的例外:

空的catch块无法实现异常的目的 至少，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.