在try-with-resources块中管理多个链接资源是否正确？

Question

当只使用一个autocloseable资源时，Java7 try-with-resources语法（也称为ARM块（自动资源管理））是很好的、简短的和直接的。但是，当我需要声明多个相互依赖的资源时，我不确定什么是正确的习惯用法，例如FileWriter和包装它的BufferedWriter。当然，这个问题涉及包装某些autocloseable资源的任何情况，而不仅仅是这两个特定的类。

我想出了以下三种选择：

static void printToFile1(String text, File file) {
    try (BufferedWriter bw = new BufferedWriter(new FileWriter(file))) {
        bw.write(text);
    } catch (IOException ex) {
        // handle ex
    }
}

这个很好，很短，但是坏了。因为底层的文件编写器不是在变量中声明的，所以它永远不会在生成的finally块中直接关闭。它将仅通过包装BufferedWriter的Close方法关闭。问题是，如果从bw的构造函数引发异常，则不会调用其close，因此不会关闭基础的文件编写器。

static void printToFile2(String text, File file) {
    try (FileWriter fw = new FileWriter(file);
            BufferedWriter bw = new BufferedWriter(fw)) {
        bw.write(text);
    } catch (IOException ex) {
        // handle ex
    }
}

在这里，底层资源和包装资源都在ARM管理的变量中声明，因此它们肯定都将被关闭，但底层fw.close()将被调用两次：不仅是直接调用，而且是通过包装的bw.close()调用。

对于这两个实现closeable（它是autocloseable的子类型）的特定类来说，这不应该是一个问题，它们的契约声明允许对close进行多次调用：

关闭此流并释放与之关联的所有系统资源。如果流已经关闭，则调用此方法不起作用。

但是，在一般情况下，我可以拥有只实现autocloseable（而不是closeable)的资源，这不能保证可以多次调用close:

注意，与java.io.Closeable的close方法不同，这个close方法不要求是幂等的。换句话说，多次调用此close方法可能会产生一些明显的副作用，这与CloSeable.close不同，如果多次调用此close方法则要求close不起作用。但是，强烈鼓励该接口的实现者使其闭式方法是幂等的。

static void printToFile3(String text, File file) {
    try (FileWriter fw = new FileWriter(file)) {
        BufferedWriter bw = new BufferedWriter(fw);
        bw.write(text);
    } catch (IOException ex) {
        // handle ex
    }
}

另一方面,语法有点不规范,而且Eclipse会发出一个警告,我认为这是一个错误警报,但仍然是一个必须处理的警告：

资源泄漏：“BW”从未关闭

那么，该走哪条路呢？还是我错过了其他正确的成语？

Answer 1

以下是我对其他选择的看法：

try (BufferedWriter bw = new BufferedWriter(new FileWriter(file))) {
    bw.write(text);
}

对我来说，15年前从传统的C++来到Java最棒的事情就是你可以信任你的程序。即使事情变得一团糟和出错（他们经常这样做），我也希望代码的其余部分保持最佳行为和良好的气味。实际上，BufferedWriter可能会在这里引发异常。例如，内存耗尽并不稀奇。对于其他decorator，您知道哪些java.io包装类从其构造函数中抛出检查异常吗？我不想。如果你依赖于那种晦涩难懂的知识，对代码的可理解性没有多大帮助。

还有“毁灭”。如果存在错误条件，那么您可能不希望将垃圾冲到需要删除的文件中（未显示该错误的代码）。当然,删除文件也是作为错误处理进行的另一个有趣的操作。

通常，您希望finally块尽可能短和可靠。html" target="_blank">添加同花顺无助于实现这一目标。对于许多版本，JDK中的一些缓冲类有一个bug，其中close中的flush异常导致修饰对象上的close无法调用。虽然这个问题已经解决了一段时间，但希望其他实现也能解决这个问题。

try (
    FileWriter fw = new FileWriter(file);
    BufferedWriter bw = new BufferedWriter(fw)
) {
    bw.write(text);
}

我们仍然在隐式finally块中进行刷新（现在使用重复的close-当添加更多的修饰符时，这会变得更糟），但是构造是安全的，我们必须隐式finally块，因此即使失败的flush也不会阻止资源释放。

try (FileWriter fw = new FileWriter(file)) {
    BufferedWriter bw = new BufferedWriter(fw);
    bw.write(text);
}

这里有个窃听器。应该是：

try (FileWriter fw = new FileWriter(file)) {
    BufferedWriter bw = new BufferedWriter(fw);
    bw.write(text);
    bw.flush();
}

一些实施不佳的装饰器实际上是资源，需要可靠地关闭。此外，有些流可能需要以特定的方式关闭（可能它们正在进行压缩，需要写入位来完成，而不能只是刷新所有内容）。

虽然3在技术上是一个优越的解决方案，但软件开发的原因使2成为更好的选择。但是，try-with-resource仍然是一个不适当的解决方法，您应该坚持使用Execute Around习语，它在Java SE8中应该有更清晰的闭包语法。