始终尝试捕获外部资源调用

仅捕获可以处理的异常。因此，例如，在使用外部资源时，最佳做法是捕获您知道可以处理的特定异常。对于文件，这可以是（IOException，SecurityException等），对于数据库，例外可以是SqlException或其他。

无论如何，不要捕获您不处理的异常，让它们流向可以处理的上层。或者，如果由于某种原因您确实捕获了异常但不处理它们，请使用 throw; （这将创建一个重新抛出的 IL 操作，而不是 trow）。

如果使用的资源，

您不知道可能会引发什么类型的异常，则被迫捕获常规异常类型。在这种情况下，安全的事情是使用来自不同应用程序域的所述资源（如果可能），或者让异常冒泡到可以显示或记录它们的顶级（ex UI）。

我认为有一个catch块有三个原因：

• 您可以处理异常并恢复（从"低级"代码）
• 您希望重新包装异常（再次，从"低级"代码）
您
• 位于堆栈的顶部，虽然您无法恢复操作本身，但您不希望整个应用程序出现故障

如果你坚持这些，与try/finally块相比，你应该有很少的 catch 块 - 而这些try/finally块几乎总是只是调用Dispose，因此最好写成using语句。

底线：有一个finally块来释放资源非常重要，但catch块通常应该更罕见。

> 知道何时设置尝试/捕获块。例如，可以通过编程方式检查可能发生的条件，而无需使用异常处理。在其他情况下，使用异常处理来捕获错误条件是合适的。

这就是我发现的，这对我来说很有意义。手动检查明显的事情，让 try-catch 完成剩下的工作。

Eric Lippert有一个很好的博客，在这里。

除非你能做一些有用的事情，否则捕获异常是没有意义的（除了"烦恼"（见博客））;在大多数情况下，你根本做不到 - 所以让它冒泡（你的UI显然应该清理并显示一些东西）。

但是，您可能有一个"尝试/最终"来处理资源管理。甚至更干净，一个"使用"块来做同样的事情。

我认为绝对的答案是完全有条件的（您如何控制环境，性能和一致性之间的预期平衡是什么，以及我敢肯定的许多其他平衡），但一般来说，我总是这样做，选择安全性而不是可能较慢的性能。

它总是取决于你想要实现的目标。服务器没有响应可能严重到足以停止所有例程做什么，并且应该将异常抛给调用方。

在其他情况下，您不在乎是否未能更新数据库。然后使用异常是可以的。

显然，您不想向最终用户显示堆栈跟踪，因此您需要在某个地方捕获它。