手艺大佬:我去,你竟然还在用 try–catch-finally

二哥,你之前那篇 我去 switch 的文章也特么太有趣了,读完后意犹未尽啊,要不要再写一篇啊?虽然用的是 Java 13 的语法,对旧版本不太友好。但谁能保证 Java 不会再来一次重大更新呢,就像 Java 8 那样,活生生地把 Java 6 拍死在了沙滩上。Java 8 是香,但早晚要升级,我挺你,二哥,别在乎那些否决的声音。

这是读者 Alice 上周特意给我发来的信息,真令我动容。简直,上次的“我去”阅读量杠杠的,几个大号都转载了,包罗 CSDN,次条当天都 1.5 万阅读。但好比“还以为你有什么新特技,没想到用的是 Java 13”这类指斥的声音也不在少数。

不外我的心一直很大。从我写第一篇文章至今,被喷的次数就好像头顶上茂密的发量一样,数也数不清。以是我决议再接再厉,带来新的一篇“我去”。

手艺大佬:我去,你竟然还在用 try–catch-finally

这次不用远程 review 了,由于我们公司也复工了。这次 review 的代码仍然是小王的,他编写的大部分代码都很漂亮,严谨的同时注释也很到位,这令我异常满足。但当我看到他没用 try-with-resources 时,照样忍不住扬声恶骂:“我擦,小王,你丫的竟然还在用 try–catch-finally!”

来看看小王写的代码吧。

public class Trycatchfinally {
    public static void main(String[] args) {
        BufferedReader br = null;
        try {
            br = new BufferedReader(new FileReader("/牛逼.txt"));
            String str = null;
            while ((str =br.readLine()) != null) {
                System.out.println(str);
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (br != null) {
                try {
                    br.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

咦,感受这段代码很完美无缺啊,try–catch-finally 用得中规中矩,尤其是文件名 牛逼.txt 很亮。不用写注释都能明了这段代码是干嘛的:在 try 块中读取文件中的内容,并一行一行地打印到控制台。若是文件找不到或者泛起 IO 读写错误,就在 catch 中捕捉并打印错误的客栈信息。最后,在 finally 中关闭缓冲字符读取器工具 BufferedReader,有用杜绝了资源未被关闭的情况下造成的严重性能效果。

在 Java 7 之前,try–catch-finally 简直是确保资源会被实时关闭的最佳方式,无论程序是否会抛出异常。

然则呢,有履历的读者会从上面这段代码中发现 2 个严重的问题:

1)文件名“牛逼.txt”包含了中文,需要通过 java.net.URLDecoder 类的 decode() 方式对其转义,否则这段代码在运行时铁定要抛出文件找不到的异常。

2)若是直接通过 new FileReader("牛逼.txt") 建立 FileReader 工具,“牛逼.txt”需要和项目的 src 在统一级目录下,否则同样会抛出文件找不到的异常。但大多数情况下,(设置)文件会放在 resources 目录下,便于编译后文件泛起在 classes 目录下,见下图。

手艺大佬:我去,你竟然还在用 try–catch-finally

为了解决以上 2 个问题,我们需要对代码举行优化:

public class TrycatchfinallyDecoder {
    public static void main(String[] args) {
        BufferedReader br = null;
        try {
            String path = TrycatchfinallyDecoder.class.getResource("/牛逼.txt").getFile();
            String decodePath = URLDecoder.decode(path,"utf-8");
            br = new BufferedReader(new FileReader(decodePath));

            String str = null;
            while ((str =br.readLine()) != null) {
                System.out.println(str);
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (br != null) {
                try {
                    br.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

运行这段代码,程序就可以将文件中的内容准确输出到控制台。但若是你对“整齐”这个词心生憧憬的话,会感受这段代码异常臃肿,尤其是 finally 中的代码,就好像一个灌了 12 瓶雪花啤酒的大肚腩。

网上看到一幅 Python 程序员讥讽 Java 程序员的神图,直接 copy 过来(侵删),逗你一乐:

手艺大佬:我去,你竟然还在用 try–catch-finally

况且,try–catch-finally 至始至终存在一个严重的隐患:try 中的 br.readLine() 有可能会抛出 IOException,finally 中的 br.close() 也有可能会抛出 IOException。如果两处都不幸地抛出了 IOException,那程序的调试义务就变得复杂了起来,到底是哪一处出了错误,就需要花一番功夫,这是我们不愿意看到的效果。

为了模拟上述情况,我们来自界说一个类 MyfinallyReadLineThrow,它有两个方式,分别是 readLine()close(),方式体都是自动抛出异常。

class MyfinallyReadLineThrow {
    public void close() throws Exception {
        throw new Exception("close");
    }

    public void readLine() throws Exception {
        throw new Exception("readLine");
    }
}

然后我们在 main() 方式中使用 try-finally 的方式挪用 MyfinallyReadLineThrow 的 readLine()close() 方式:

public class TryfinallyCustomReadLineThrow {
    public static void main(String[] args) throws Exception {
        MyfinallyReadLineThrow myThrow = null;
        try {
            myThrow = new MyfinallyReadLineThrow();
            myThrow.readLine();
        } finally {
            myThrow.close();
        }
    }
}

运行上述代码后,错误客栈如下所示:

Exception in thread "mainjava.lang.Exceptionclose
    at com.cmower.dzone.trycatchfinally.MyfinallyOutThrow.close(TryfinallyCustomOutThrow.java:17)
    at com.cmower.dzone.trycatchfinally.TryfinallyCustomOutThrow.main(TryfinallyCustomOutThrow.java:10)

readLine() 方式的异常信息竟然被 close() 方式的客栈信息吃了,这必然会让我们误以为要观察的目的是 close() 方式而不是 readLine()——只管它也是应该嫌疑的工具。

从零开始发布一个ArcGIS Server地图服务

但自从有了 try-with-resources,这些问题就迎刃而解了,只要需要释放的资源(好比 BufferedReader)实现了 AutoCloseable 接口。有了解决方案之后,我们来对之前的 finally 代码块举行瘦身。

try (BufferedReader br = new BufferedReader(new FileReader(decodePath));) {
    String str = null;
    while ((str =br.readLine()) != null) {
        System.out.println(str);
    }
catch (IOException e) {
    e.printStackTrace();
}

你瞧,finally 代码块消逝了,取而代之的是把要释放的资源写在 try 后的 () 中。若是有多个资源(BufferedReader 和 PrintWriter)需要释放的话,可以直接在 () 中添加。

try (BufferedReader br = new BufferedReader(new FileReader(decodePath));
     PrintWriter writer = new PrintWriter(new File(writePath))) {
    String str = null;
    while ((str =br.readLine()) != null) {
        writer.print(str);
    }
catch (IOException e) {
    e.printStackTrace();
}

若是你想释放自界说资源的话,只要让它实现 AutoCloseable 接口,并提供 close() 方式即可。

public class TrywithresourcesCustom {
    public static void main(String[] args) {
        try (MyResource resource = new MyResource();) {
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

class MyResource implements AutoCloseable {
    @Override
    public void close() throws Exception {
        System.out.println("关闭自界说资源");
    }
}

代码运行后输出的效果如下所示:

关闭自界说资源

是不是很神奇?我们在 try () 中只是 new 了一个 MyResource 的工具,其他什么也没干,但偏偏 close() 方式中的输出语句执行了。想要知道为什么吗?来看看反编译后的字节码吧。

class MyResource implements AutoCloseable {
    MyResource() {
    }

    public void close() throws Exception {
        System.out.println("关闭自界说资源");
    }
}

public class TrywithresourcesCustom {
    public TrywithresourcesCustom() {
    }

    public static void main(String[] args) {
        try {
            MyResource resource = new MyResource();
            resource.close();
        } catch (Exception var2) {
            var2.printStackTrace();
        }

    }
}

咦,编译器竟然自动为 try-with-resources 举行了变身,在 try 中挪用了 close() 方式。

接下来,我们在自界说类中再添加一个 out() 方式,

class MyResourceOut implements AutoCloseable {
    @Override
    public void close() throws Exception {
        System.out.println("关闭自界说资源");
    }

    public void out() throws Exception{
        System.out.println("缄默王二,一枚有趣的程序员");
    }
}

这次,我们在 try 中挪用一下 out() 方式:

public class TrywithresourcesCustomOut {
    public static void main(String[] args) {
        try (MyResourceOut resource = new MyResourceOut();) {
            resource.out();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

再来看一下反编译的字节码:

public class TrywithresourcesCustomOut {
    public TrywithresourcesCustomOut({
    }

    public static void main(String[] args{
        try {
            MyResourceOut resource = new MyResourceOut();

            try {
                resource.out();
            } catch (Throwable var5) {
                try {
                    resource.close();
                } catch (Throwable var4) {
                    var5.addSuppressed(var4);
                }

                throw var5;
            }

            resource.close();
        } catch (Exception var6) {
            var6.printStackTrace();
        }

    }
}

这次,catch 块中自动挪用了 resource.close(),而且有一段很要害的代码 var5.addSuppressed(var4)。它有什么用处呢?当一个异常被抛出的时刻,可能有其他异常由于该异常而被抑制住,从而无法正常抛出。这时可以通过 addSuppressed() 方式把这些被抑制的方式记录下来。被抑制的异常会泛起在抛出的异常的客栈信息中,也可以通过 getSuppressed() 方式来获取这些异常。这样做的利益是不会丢失任何异常,利便我们开发人员举行调试。

哇,有没有想到我们之前的谁人例子——在 try-finally 中,readLine() 方式的异常信息竟然被 close() 方式的客栈信息吃了。现在有了 try-with-resources,再来看看作用和 readLine() 方式一致的 out() 方式会不会被 close() 吃掉。

close()out() 方式中直接抛出异常:

class MyResourceOutThrow implements AutoCloseable {
    @Override
    public void close() throws Exception {
        throw  new Exception("close()");
    }

    public void out() throws Exception{
        throw new Exception("out()");
    }
}

挪用这 2 个方式:

public class TrywithresourcesCustomOutThrow {
    public static void main(String[] args) {
        try (MyResourceOutThrow resource = new MyResourceOutThrow();) {
            resource.out();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

程序输出的效果如下所示:

java.lang.Exceptionout()
    at com.cmower.dzone.trycatchfinally.MyResourceOutThrow.out(TrywithresourcesCustomOutThrow.java:20)
    at com.cmower.dzone.trycatchfinally.TrywithresourcesCustomOutThrow.main(TrywithresourcesCustomOutThrow.java:6)
    Suppressedjava.lang.Exceptionclose()
        at com.cmower.dzone.trycatchfinally.MyResourceOutThrow.close(TrywithresourcesCustomOutThrow.java:16)
        at com.cmower.dzone.trycatchfinally.TrywithresourcesCustomOutThrow.main(TrywithresourcesCustomOutThrow.java:5)

瞧,这次不会了,out() 的异常客栈信息打印出来了,而且 close() 方式的客栈信息上加了一个要害字 Suppressed。一目了然,不错不错,我喜欢。

总结一下,在处置必须关闭的资源时,始终有限思量使用 try-with-resources,而不是 try–catch-finally。前者发生的代码加倍简练、清晰,发生的异常信息也更靠谱。准许我好不好?别再用 try–catch-finally 了。

手艺大佬:我去,你竟然还在用 try–catch-finally

鸣谢

好了,我亲爱的读者同伙,以上就是本文的全部内容了,是不是感受又学到了新知识?我是缄默王二,一枚有趣的程序员。原创不易,莫要白票,请你为本文点赞个吧,这将是我写作更多优质文章的最强动力。

若是以为文章对你有点辅助,请微信搜索「 缄默王二 」第一时间阅读,回复【666】更有我为你经心准备的 500G 高清教学视频(已分门别类)。本文 GitHub 已经收录,有大厂面试完整考点,迎接 Star。

原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/4033.html