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

Question

我是否应该始终在try-catch中包装外部资源调用？ （即调用数据库或文件系统）调用外部资源时是否有最佳的错误处理方法？

Answer 1

抓住可以处理的唯一例外 。因此，例如在使用外部资源时，最佳做法是捕获您知道可以处理的特定异常。如果是文件，则可以是（IOException，SecurityException等），对于Database，异常可以是SqlException或其他。

在任何情况下，不会抓住不处理的例外，让它们流向可以的上层。或者，如果由于某种原因你捕获异常但不处理它们，只需使用 throw; 重新抛出它们（这将创建一个重新抛出IL op，而不是trow）。

如果使用的资源不知道可能抛出什么类型的异常，那么您将被迫捕获常规异常类型。在这种情况下，保险箱的用途是使用来自不同应用程序域的所述资源（如果可能的话），或者让异常泡到最高级别（从UI开始），在那里可以显示或记录它们。

Answer 2

我认为有一个阻止块有三个原因：

• 您可以处理异常并恢复（从“低级别”代码）
• 您想要重新包装异常（再次，从“低级别”代码）
• 你处于堆叠的顶端，虽然你无法自行恢复操作，但你不希望整个应用程序崩溃

如果坚持这些，与try/finally块相比，你应该只有很少的捕获块 - 而那些try/finally块几乎总是只调用Dispose，因此最好写成{ {1}}陈述。

结论：拥有using块来释放资源非常重要，但finally块通常应该更少见。

Answer 3

> Know when to set up a try/catch block. For example, you can programmatically check for a condition that is likely to occur without using exception handling. In other situations, using exception handling to catch an error condition is appropriate.

这就是我发现的东西，对我来说很有意义。手动检查明显的东西，让try-catch做其余的事情。

Answer 4

Eric Lippert有一个很好的博客，here。

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

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

Answer 5

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

Answer 6

它总是取决于你想要达到的目标。没有响应的服务器可能严重到足以阻止例程正在做的事情，并且应该向调用者抛出异常。

在其他情况下，您不关心是否未能更新数据库。然后消耗异常就可以了。

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