将所有东西包装在try/catch块中是否构成防御性编程？

Question

我在过去的三年里一直在编程。当我编程时，我使用来处理所有已知的异常，并优雅地提醒用户。我最近看到了一些代码，其中几乎所有的方法都包装在try/catch块中。作者说，这是防御性编程的一部分。我想知道，这真的是防御性编程吗？您是否建议将所有代码放在try块中？

Answer 1

我的基本规则是:除非你可以修复导致异常的问题，否则不要捕获它，让它冒泡到可以处理的级别。

根据我的经验，95%的catch块要么忽略异常(catch {})，要么记录错误并重新抛出异常。后者看起来似乎是正确的做法，但实际上，当在每个级别上执行此操作时，您的日志只会杂乱地堆满同一错误消息的五个副本。通常，这些应用程序在最高层有一个“忽略捕获”(因为“我们在所有较低层都尝试/捕获”)，导致应用程序非常慢，有许多遗漏的异常，并且错误日志太长，任何人都不愿意查看它。

Answer 2

广泛使用Try...Catch不是防御性编程，它只是将身体钉在直立位置的。

面对意想不到的异常，Try...Finally可以广泛用于恢复。只有当你期望一个异常，以及现在如何处理它时，你才应该使用Try..Catch。

有时我会看到Try..Catch System.Exception，它的catch块只是记录异常并重新抛出。这种方法至少存在3个问题：

• 重新抛出假设了一个未处理的异常，因此程序应该终止，因为它处于未知状态。但是catch会导致Catch块下面的Finally块运行。在未定义的情况下，这些Finally块中的代码可能会使问题变得更糟。
• 这些块中的代码将改变程序状态。因此，当异常最初被抛出时，任何日志记录都不会捕获实际的程序状态。调查将会更加困难，因为状态已经改变了。
• 它会给您带来糟糕的调试体验，因为调试器会在重新抛出时停止，而不是在最初的抛出时停止。

Answer 3

不，这不是“防御性编程”你的同事正试图通过用一个时髦的词来描述一个好习惯来使他的坏习惯变得合理。

他的所作所为应该被称为“把它扫到地毯下”。它就像uniformly (void)-ing方法调用的错误状态返回值。