我应该总是将我的代码包装在try ... catch块中吗？

Question

  

可能重复：
  When to use try/catch blocks?
  Main method code entirely inside try/catch: Is it bad practice?
  When to use Try Catch blocks

可以在任何地方发生异常，所以这让我想到：我应该总是将我的代码包装在try..catch块中吗？

这是针对C＃。

（我可能会遗漏一些基本的东西，因为我还是新手）

编辑：看来这确实不是一个非常聪明的问题。我们在学校唯一学到的就是使用try ... catch来防止崩溃。我们在例外情况下所做的是显示一个MessageBox，告诉用户在编写此文件时出现问题＆＃39;。

Answer 1

  

可以在任何地方发生异常，所以这让我想到：我应该总是将我的代码包装在try..catch块中吗？

好问题。这是一个相关的问题：

  持斧的疯子几乎可以在任何地方，所以：我应该每天24小时都穿着抗斧的防弹衣吗？

我很幸运能够生活在一个斧头挥舞的疯子数量足够低的地方，当我离开家时，我不穿盔甲。但是假设我没有。 是否一直穿着盔甲或者监禁疯子是正确的解决方案？

如果你的程序抛出了很多异常，你需要在任何地方处理这些异常，那么你就会遇到很大的问题。该问题的解决方案不是装备并在各处进行异常处理。该问题的解决方案是消除抛出异常的代码，如果你无法消除它，那么将它隔离到一个使用异常处理的微小代码区域

Answer 2

绝对不是。这是一个很棒的CodeProject article on working with exceptions让你前进。

但更重要的是，在OP中，只应在需要处理的情况下处理异常。这意味着一个良好实现的应用程序将在应用程序中有几个点（取决于当然的范围），其中将处理许多特定的，异常派生的异常，甚至更少的地方（每个线程每个最佳实践一个）建议）将处理通用异常。

使用异常时，不要考虑返回错误信息的函数。异常极大地减轻了通过调用链渗透错误情况的繁琐。

Answer 3

不，你不应该把所有代码都包装在try-catch中。我在dba.stackexchange.com上回答了类似的问题 - how much overhead an error in RDBMS has。

通常，如果您要对错误消息执行特定操作，或者如果失败的代码生成的结果不在其他任何地方使用，则应该只使用异常处理。如果应用程序面向用户，您显然不希望他们看到原始异常消息。在所有这些情况下，您应该记录失败...没有意义捕获您不打算处理的异常（空catch =坏）。但除此之外，你会想要抛出异常。

例如，您进行数据库调用，但它因SQL异常而失败。代码的下一部分旨在处理该结果，因此您需要抛出异常并暂停程序执行。

如果您的代码经常产生异常（并且驱动逻辑偏离），您可能应该重新考虑您的方法。