总是尝试捕获外部资源调用？

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

这始终取决于您想要实现的目标。服务器没有响应可能严重到足以停止所有例程，并且应该将异常抛给调用方。

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

显然，您不希望向最终用户显示堆栈跟踪，因此您需要在某处捕获它。

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

这就是我发现的，这对我来说很有意义。手动检查显而易见的事情，剩下的就交给 try-catch 吧。

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

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

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

埃里克·利珀特（Eric Lippert）在这里有一个很好的博客。

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

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

我认为有三个原因可以阻止：

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

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

一句话：有一个区块来释放资源非常重要，但区块通常应该更稀有。finallycatch