您是否真的需要“最终”障碍

我认为willpre最接近在这里表达关键点，也许每个人都知道，但不清楚。

问题是您的要求确实存在一些问题：“如果我在catch块之后编写所有语句，而不是将它们写入到finally块中，那么会出错吗？”

如果将所有语句写在catch块之后，则意味着

1）您将始终捕获异常。

2）捕获异常后，您将始终继续执行下一条语句。

这意味着您将始终在异常发生后“正常”继续执行，这实际上是您实际上 从未 希望执行的事情。

例外应该就是这样-例外。如果实际上您可以处理异常，那么编写代码时首先考虑这些条件总是更好，而根本不要导致异常。如果您遵循此模型，那么异常确实是例外-
您无法预期或至多无法解决的情况。真的没想到您应该努力。 这通常意味着您无法处理真正的异常，这也意味着您不应该只是继续执行，而通常是结束应用程序。

通常要做的是允许错误传播回调用堆栈。有人说，这样做是偶然的，链中较高的某个人可能会处理它。我要说的是，从没有发生过，这样做有两个实际目的。一种可能是用户可以修复的东西，如果有的话。因此，您可以将错误传播回去，直到到达可以将其报告给用户的位置为止。或两个，用户无法修复它，但您想获取整个调用堆栈进行调试。然后，将其捕获到顶部即可正常失败。

现在，finally块对您应该具有更多的意义。大家都说它总是运行。对finally的最清晰使用实际上是在尝试…
finally块。您现在要说的是，如果代码运行正常，那就太好了。我们仍然需要进行一些清理，并且最终总是执行然后继续。但是，如果发生异常，我们现在确实需要finally块，因为我们可能仍需要进行一些清理，但是我们不再在这里捕获异常，因此我们不再继续。对于确保清除发生，finally块是必不可少的。

异常总是使执行停止的想法可能很难被某人掌握，除非他们有一定的经验，但这实际上是总是做事的方式。如果发生了错误，那么它可能很小，您应该首先考虑它，否则，越来越多的错误等待发生。

“吞并”错误-捕获它们并继续前进是您最糟糕的事情，因为程序变得不可预测，并且您无法找到并修复错误。

编写良好的代码将包含必要的try … finally块，以确保无论结果如何，始终释放资源。但是编写良好的代码通常只包含少量的try …
catch块，这些块主要是为了使应用程序尽可能正常地失败或延迟用户而存在，这意味着至少始终将消息传递给用户等。但是您通常不只是发现错误并继续前进。