java - ZipOutputStream 类的 closeEntry()

标签 java java-7 try-catch-finally try-with-resources zipoutputstream

我正在使用 Java7 编写代码,并使用 try-with-resources 功能。 当我创建 ZipOutputStream 的实例时。通过这样做,我不再需要在finally block 中关闭流。 try-with-resources 管理了这个(当然是通过 JVM)。
我的问题是 - closeEntry() 的使用怎么样。我应该在 try block 中编写此方法,还是应该删除它,然后 JVM 将通过 try-with-resources 功能自动关闭它,就像使用 close() 方法一样?

我几乎可以肯定它与 try-with-resources (或与 finally block )无关,我应该在 try block 内而不是在 finally block 中执行此操作(如果我使用常规 try- catch-finally),但我想确定一下。

谢谢!!!

最佳答案

what about the use of closeEntry(). Should I write this method in my try block or should I delete it and the JVM will close it automatically by the try-with-resources feature just like it does with the method close()?

如果您希望调用 closeEntry(),那么您应该安排它的调用。当退出 try-with-resources block 时,它不会自动调用——至少不会直接调用。也不应该如此,因为 closeEntry() 在逻辑上与 putNextEntry() 配对,并且输入 try block 的主体不会导致 putNextEntry() 被调用。

如果实际上一个条目在调用时是打开的,则流关闭可能会包含 closeEntry() 的效果。然而,这没有记录在案,因此最安全的做法是确实确保在最后一个条目之后调用 closeEntry()。您还可以在条目之间调用它,但不需要这样做,因为 putNextEntry() 已记录为在开始新条目之前关闭所有打开的条目。

关于java - ZipOutputStream 类的 closeEntry(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40468385/

相关文章:

java - 无法使 kie-drools-workbench-6.2 在 tomcat 7 上工作

java - 用 JSP 的类文件而不是 JSP 本身来传送 WAR 更好吗?

java - 在 React Native Android 应用程序中通过 crashlytics 的堆栈跟踪找到崩溃是真的吗?

Java 7 - 多行字符串

Java向后兼容性说明

java - 我不会在finally block 中使用try-catch 语句。 (java)

java - 在 Java 中,当 catch block 和 finally block 都抛出异常时会发生什么?

java - JSP 和 derby 数据库类

java - OutOfMemoryException(升级到 JDK 7u45 后)

java - SonarQube,finally block 中的跳转语句(squid :S1143)