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

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

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

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

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

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

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

异常日志记录;根据上下文的不同，您可能希望发布一个未处理的异常或消息。 循环技术情况，如渲染或声音处理或列表框回调，行为本身将演示问题，抛出异常将只是阻碍，记录异常可能只会导致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，它可能更适合呈现调用，这样异常就不会生成无穷无尽的消息。

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

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

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