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

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

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

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

你不应该有一个空的catch块。这就像隐藏一个你知道的错误。至少，您应该为日志文件编写一个异常，以便稍后在时间紧迫时查看。

这可能从来都不是正确的事情，因为您正在默默地传递每个可能的异常。如果有您期望的特定异常，那么您应该测试它，如果它不是您的异常则重新抛出。

try
{
    // Do some processing.
}
catch (FileNotFound fnf)
{
    HandleFileNotFound(fnf);
}
catch (Exception e)
{
    if (!IsGenericButExpected(e))
        throw;
}

public bool IsGenericButExpected(Exception exception)
{
    var expected = false;
    if (exception.Message == "some expected message")
    {
        // Handle gracefully ... ie. log or something.
        expected = true;
    }

    return expected;
}

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

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