【问题标题】:Java try - finally designJava try - finally 设计
【发布时间】:2016-08-16 21:26:37
【问题描述】:

在 JDK 6 及更低版本中,我看到许多带有 try - finally 块的代码 sn-ps,如下所示。

private void doSomething() throws IOException {
    FileReader reader = null;
    try {
        reader = new FileReader("someFile");
        .....
    } finally {
        if(reader != null){
            reader.close();
        }
    }
}

为什么要将 reader 初始化为 null,然后在 try 块中分配它。下面的模板会更好(想知道我是否遗漏了什么)?我的理由...我们避免 null check in finally 块,如果阅读器未能初始化,那么我不必做任何其他事情。

private void doSomething() throws IOException {
    FileReader reader = new FileReader("someFile");
    try {

        .....
    } finally {
        reader.close();
    }
}

【问题讨论】:

  • 不是真的!如果构造函数抛出异常,该方法的其余部分无论如何都无事可做。看到 throws 子句了吗?

标签: try-finally


【解决方案1】:

单独声明没有问题,但是当您添加更多需要关闭的资源时,您会开始获得一堆未关闭的资源。最好将它们声明为null,并在内部使用finally 处理关闭。

执行不力

private void doSomething() throws IOException {
    FileReader reader = new FileReader("someFile");
    FileWriter writer = new FileWriter("someFile2"); //throws exception
    try {

        .....
    } finally {
        reader.close();
        writer.close();
    }
} //reader remains unclosed

现在我们有一个未关闭的 FileReader,因为另一个构造函数抛出了异常。

正确实施

private void doSomething() throws IOException {
    FileReader reader = null;
    FileWriter writer = null;
    try {
        reader = new FileReader("someFile");
        writer = new FileWriter("someFile2"); //throws exception
    } finally {
        if(reader != null)
            reader.close(); //closes properly
        if(writer != null) //skipped
            writer.close();
    }
}

【讨论】:

  • 我不是在处理多个资源...所以这不适用
  • @Stackee007 这是约定俗成的,如果以后您决定使用两种资源,则不必重构代码来支持它。
猜你喜欢
  • 2011-05-10
  • 2011-02-13
  • 2011-10-31
  • 2016-12-05
  • 2011-11-17
  • 2015-09-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多