Java Try-With-Resources 辩论

Question

现在，在我的工作中，我们正在就 try-with-resources 和异常抑制进行辩论。

快速回顾:来自 Java 7 的 try-with-resources 消除了使用讨厌的 finally block 来关闭资源的需要。我个人觉得它更优雅，但我有一个同事不相信。他不喜欢一个异常(exception)被抑制，并且一直认为我们会因此而丢失信息。

起初我相信他的话，因为我是初级开发人员而他是高级开发人员，我是新手，等等。但我最近发现，嘿，所有信息都进入了堆栈跟踪，包括被抑制的异常。所以那里没有信息丢失。

我正在寻找的这场辩论的最后一部分(因为我提倡尝试使用资源)是自动关闭如何处理该异常。假设在尝试关闭资源时抛出异常，资源是否有可能保持打开状态并泄漏？最终这可能不是什么大问题，因为无论如何日志都会提醒我们注意这个问题。

只是好奇。非常感谢。

Answer 1

您是正确的，抑制异常不会导致信息丢失。你的同事对此的担忧是没有根据的。 try-with-resources 的要点是:

• 确保资源被关闭，无论在使用它们时抛出什么，并且以它们声明的相反顺序，

• 确保关闭时抛出的异常不会导致 try block 中抛出的异常丢失，并且

• 确保关闭时抛出的异常仍作为抑制异常保留，因此不会丢失任何信息。

如果关闭资源会引发异常，那么在这两种情况下您都无能为力。在 JDBC 中，数据库对象与数据库服务器通信，告诉它取消分配资源，如果关闭失败，这些对象将保持打开状态。 (而且重试通常毫无意义，因为问题通常是网络或连接发生了某些变化。)但是服务器最终会清除这些，并且它不在客户端代码的控制范围内。 try-with-resources 和较早的 try-finally 习惯用法在关闭资源方面做得同样出色，只是使用 try-finally 习惯用法需要更多工作和更多输入。

使用 try-with-resources 还是嵌套的 try-finally 语句对我来说最大的区别是，在前一种情况下，如果在 try block 中没有抛出任何东西并且在关闭时抛出某些东西，则在关闭时抛出异常被抛出(因为在 try block 中没有抛出异常以将其作为抑制异常附加到)。如果您使用嵌套的 try-finally block ，那么您可以确保关闭时抛出的异常不会从 finally block 传播，这样释放资源时的间歇性网络故障不会导致丢失有效的业务事务。

但在实践中，很少有人能够容忍这种嵌套，他们会走捷径导致资源泄漏(通常是因为 finally block 中的早期调用失败而无法关闭的连接)。人们还倾向于编写导致异常屏蔽的代码(在第二个要点中提到)，其中关闭时抛出的异常导致 try block 内抛出的异常丢失； try-with-resources 可以防止这种错误。肯定有尝试资源的地方。

我的建议是尽可能多地学习异常处理，编写示例程序来演示异常的工作原理，并了解这两种方法的优缺点，以便您可以详细讨论它们并进行比较和对比。这样你就可以表明你理解你的同事提出的问题，你可以提供建议，而不是作为一种方式的倡导者，而是以帮助你的团队找到有助于编写更好软件的解决方案为目标。