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

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

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

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

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

在极少数情况下，这样做是合理的。在Python中，你经常会看到这样的结构:

try:
    result = foo()
except ValueError:
    result = None

所以它可能是OK的(取决于你的应用程序):

result = bar()
if result == None:
    try:
        result = foo()
    except ValueError:
        pass # Python pass is equivalent to { } in curly-brace languages
 # Now result == None if bar() returned None *and* foo() failed

在最近的一个. net项目中，我必须编写代码来枚举插件dll，以查找实现特定接口的类。相关的代码(在VB中。NET，对不起)是:

    For Each dllFile As String In dllFiles
        Try
            ' Try to load the DLL as a .NET Assembly
            Dim dll As Assembly = Assembly.LoadFile(dllFile)
            ' Loop through the classes in the DLL
            For Each cls As Type In dll.GetExportedTypes()
                ' Does this class implement the interface?
                If interfaceType.IsAssignableFrom(cls) Then

                    ' ... more code here ...

                End If
            Next
        Catch ex As Exception
            ' Unable to load the Assembly or enumerate types -- just ignore
        End Try
    Next

尽管在这种情况下，我承认在某个地方记录失败可能是一种改进。

一般来说，这是一个坏主意，因为这是一个真正罕见的情况，即失败(更普遍的情况是例外情况)没有得到任何回应。最重要的是，空捕获块是使用异常引擎进行错误检查的人使用的常用工具，他们应该先发制人地进行错误检查。

说它总是不好是不真实的……这种情况很少发生。在某些情况下，您不关心是否存在错误，或者错误的存在以某种方式表明您无法对其采取任何措施(例如，当将以前的错误写入文本日志文件时，您得到一个IOException，这意味着您无论如何都不能写出新的错误)。

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

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