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

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

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

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

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

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

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

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

在某些情况下，您可能会使用它们，但它们应该非常不频繁。我可能会使用它的情况包括:

异常日志记录;根据上下文的不同，您可能希望发布一个未处理的异常或消息。 循环技术情况，如渲染或声音处理或列表框回调，行为本身将演示问题，抛出异常将只是阻碍，记录异常可能只会导致1000个“失败到XXX”消息。 不能失败的程序，尽管它们至少应该记录一些东西。

对于大多数winforms应用程序，我发现对于每个用户输入都有一个try语句就足够了。我使用以下方法:(AlertBox只是一个快速的消息框。显示包装)

  public static bool TryAction(Action pAction)
  {
     try { pAction(); return true; }
     catch (Exception exception)
     {
        LogException(exception);
        return false;
     }
  }

  public static bool TryActionQuietly(Action pAction)
  {
     try { pAction(); return true; }
     catch(Exception exception)
     {
        LogExceptionQuietly(exception);
        return false;
     }
  }

  public static void LogException(Exception pException)
  {
     try
     {
        AlertBox(pException, true);
        LogExceptionQuietly(pException);
     }
     catch { }
  }

  public static void LogExceptionQuietly(Exception pException)
  {
     try { Debug.WriteLine("Exception: {0}", pException.Message); } catch { }
  }

然后每个事件处理程序都可以这样做:

  private void mCloseToolStripMenuItem_Click(object pSender, EventArgs pEventArgs)
  {
     EditorDefines.TryAction(Dispose);
  }

or

  private void MainForm_Paint(object pSender, PaintEventArgs pEventArgs)
  {
     EditorDefines.TryActionQuietly(() => Render(pEventArgs));
  }

理论上，您可以使用tryactionsilent，它可能更适合呈现调用，这样异常就不会生成无穷无尽的消息。

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

空的catch块无法实现异常的目的 至少，catch块应该包含一个注释，解释为什么忽略异常是合适的。