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

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

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

空的catch块通常被放入，因为编码器并不真正知道他们在做什么。在我的组织中，一个空的catch块必须包含一个注释，说明为什么不处理异常是一个好主意。

与此相关的是，大多数人不知道try{}块后面可以跟catch{}或finally{}，只有一个是必需的。

这与“不要使用异常来控制程序流”和“只在异常情况下使用异常”是密切相关的。如果执行了这些操作，那么只有在出现问题时才会出现异常。如果出现了问题，你也不想默默地失败。在不需要处理问题的罕见异常中，您至少应该记录异常，以防异常不再是异常。比失败更糟糕的是默默的失败。

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

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

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

在极少数情况下，这样做是合理的。在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

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

我发现最令人讨厌的空catch语句是其他程序员做的。我的意思是，当您需要调试别人的代码时，任何空的catch语句都会使这种工作变得更加困难。恕我直言，catch语句应该总是显示某种错误消息——即使错误没有被处理，它至少应该检测到它(只在调试模式下启用)