问题标签 [try-with-resources]

以下两个选项之间是否存在语义差异？在自动资源管理方面，它们中的任何一个都比另一个更安全吗？

选项1：

选项2：

使用 SonarQube 的最新版本 (4.3.2)，try-with-resources 块会误报catch线路的分支覆盖率。例如：

但是我的单元测试涵盖了在每个点抛出的异常，并且所有其他行都有 100% 的覆盖率——实际的覆盖率是 100%。“8”从何而来？没有 8 个地方可以抛出异常。

我尝试添加// NOSONAR到问题行，甚至尝试将其添加到每一行，但报告是一样的。

使用时忽略了其他类型的问题// NOSONAR，因此不是声纳配置问题。

我怀疑这是因为声纳不允许在 try-with-resources 块产生的字节码中使用额外的 try-catch 块。

有没有办法装饰成功导致声纳忽略这个特定误报的代码？

我想使用 Java 的 try-with-resources 安全、完全地关闭多个流。我不知道我必须有多冗长。我想确保我的资源得到充分处置。我的代码是这样工作的：

我想知道这是否是矫枉过正，如果我能做到这一点：

我碰巧意识到，情况就是这样。请参阅下面的示例：

它打印：

尝试
关闭。 终于
抓到了

问题

try-with-resources 旨在避免带有 null 检查的混乱 finally 部分，并避免资源泄漏。为什么在 catch 部分之前关闭资源？其背后的原因/想法/限制是什么？

FilterOutputStream.close()这是对 Java 8 中方法的更改，这给我们带来了一些问题。（见http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf）

在以前的 Java 版本中，以下代码可以正常工作而不会引发异常。但是，在 Java 8 下，当 try-with-resources 机制关闭流时，我们总是会遇到异常。

try-with-resources 机制将首先调用close(). deflaterStream由于deflaterStreamwraps boswhich wraps outStream，deflaterStream.close()将调用bos.close()which 将调用outStream.close()which 关闭数据库的底层流。

try-with-resources 机制接下来会调用close(). bos由于bosextends FilterOutputStream，flush()将首先被调用outStream。但是，由于outStream已经关闭，outStream.flush()抛出异常：java.sql.SQLException: Closed LOB

有没有其他人遇到过这个问题？如果是这样，您是如何解决的？我们使用 try-with-resources 的方式有问题吗？

从 Java 7 开始，Closeable接口已被改造为扩展AutoCloseable接口，以便所有实现Closeable接口的类都可以使用try-with-resources语句。到目前为止，Closeable 接口可以自由地抛出任何异常，包括 InterrruptedException。try-with-resources但是，在 Java 7 中，当退出 try 块后自动调用 close 方法时，语句中使用的 Closeable 接口的任何实例都可能抛出 InterruptedException，并且它InterruptedException可能会被隐式调用抑制Throwable.addSuppressed(InterruptedException);

考虑到有人可能会在不知不觉中抑制其异常并且程序没有按应有的方式运行，这是否违反了 Java 的向后兼容性规则

例如，如果一个资源的实例需要在不同的对象中传递怎么办？

由于 try-with-resource 的设计（正确地）旨在限制其成员的范围，那么有人将如何处理这种设计问题？

还在使用 try-with-resources 并不断地传递实例吗？使用常规的 try-catch-finally 块并将成员保持在其范围之外？

我读到catchtry-with-resources 中的块是可选的。我尝试Connection在 try-with-resources 块中创建一个对象，没有后续catch块，只是从 eclipse 中获取编译器错误：“自动调用SQLException引发的未处理异常类型。”close()

由于可以在 try-with-resources 中使用的每个资源都实现AutoCloseable，因此在调用该方法时可能会引发异常，因此close()我不明白该catch子句如何是可选的，因为它不允许我跳过从close().

是不是有什么特殊要求，具体实现AutoCloseable不直接声明其close()方法中抛出的异常？（例如，使用不抛出任何异常 AutoCloseable的覆盖）？close() throws Exceptionclose()

..或者这可能只是一个日食问题？

编辑：这是仍然触发问题的最简单的代码片段：

关于这是否与使用 JNDI 数据源有关的想法？

提前致谢。

我正在为我的学校项目重写我的 AudioManager 课程，但遇到了一个问题。我的教授告诉我使用 Try-with-resources 块而不是使用 try/catch 加载我的所有资源（参见下面的代码）。我正在使用 javax.sound.sampled.Clip 中的 Clip 类，如果我不 close() Clip，一切都与我的 PlaySound(String path) 方法完美配合，该方法使用 try/catch/。我知道如果我关闭（）剪辑我不能再使用它了。我已阅读有关 Clip 和 Try-with-resources 的 Oracle 文档，但找不到解决方案。所以我想知道的是：

是否可以使用 Try-with-resource 块在剪辑关闭之前播放/收听剪辑中的声音？

提前致谢！

我学习了 java 7 功能try with resources。

在 catch 块中，我应该处理来自try（通常）和来自的异常finally

这是否意味着 finally 在 catch 之前被调用？如果我想在 catch 中处理 Closeable 资源怎么办？

有一个观察结果证实了我的假设。

如果 try 块抛出异常 1 并且资源的关闭方法抛出异常 2，则异常 1 将被捕获，异常 2 将被抑制。