Java试用资源辩论

Question

好的，现在，在我的工作中，我们正在就尝试资源和异常抑制进行辩论。

快速回顾：来自Java 7的try-with-resources消除了对讨厌的final块关闭资源的需求。 我个人觉得它更优雅，但是我有一个不相信的同事。 他不喜欢抑制一个例外，并且一直在争论我们通过那个例外来释放信息。

起初，我是听他的话的，因为我是一个初级开发人员，他是高级，我是新手，等等。但是我最近发现，嘿，所有信息都将其放入堆栈跟踪，包括被抑制的异常。 因此，那里没有任何信息丢失。

我正在寻找的辩论的最后一部分（因为我主张使用try-with-resources）是自动关闭如何处理该异常。 假设在尝试关闭资源时抛出了异常，是否有可能资源保持打开和泄漏的可能性？ 最终，这可能没什么大不了的，因为无论如何日志都会提醒我们注意此问题。

只是好奇。 非常感谢。

Answer 1

您是正确的，抑制异常不会导致信息丢失。 您的同事对此的担忧是没有根据的。 尝试资源的要点是：

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

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

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

如果关闭资源引发异常，则在任何一种情况下您都无能为力。 在JDBC中，数据库对象传回数据库服务器以告诉它取消分配资源，如果关闭失败，它们将保持打开状态。 （无论如何，重试通常是没有意义的，因为问题通常是网络或连接发生了变化。）但是服务器最终将清理掉这些内容，这不在客户端代码的控制范围之内。 使用资源的尝试方法和较旧的尝试-最终习惯用法在关闭资源方面都做得同样好，尝试-最终习惯用语的工作量更大，打字也更多。

对于我而言，无论是使用try-with-resources还是嵌套的try-finally语句，最大的区别在于，在前一种情况下，如果try块中没有抛出任何异常，并且在close上抛出了异常，则在close上抛出了异常（因为在try块中没有抛出任何异常以将其附加为受抑制的异常）。 如果使用嵌套的try-finally块，则可以确保在close块上抛出的异常不会从finally块传播，这样在释放资源时出现间歇性网络故障不会导致丢失有效的业务交易。

但是在实践中，很少有人能容忍这种嵌套，并且他们采取了导致资源泄漏的捷径（通常，由于在finally块中的较早调用失败而导致连接无法关闭）。 人们还倾向于编写导致异常屏蔽的代码（在第二个要点中提到），其中抛出在关闭状态的异常会导致在try块内抛出的异常丢失。 try-with-resources可以防止这种错误。 绝对有一个尝试资源的地方。

我的建议是学习有关异常处理的所有知识，编写示例程序演示异常的工作方式，并了解两种方法的优缺点，以便您可以详细讨论它们以及进行比较和对比。 这样，您可以表明自己了解同事提出的问题，并且可以提供建议，而不是作为一种倡导者来代替另一种方法，而是旨在帮助您的小组找到有助于其编写更好软件的解决方案。