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

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

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

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

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

我只能想到一些空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块基本上表示“一些不好的事情正在发生，但我只是不在乎”。这是个坏主意。

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

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

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

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