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

简介: 技术大佬:我去,你竟然还在用 try–catch-finally

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

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


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




这次不用远程 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 目录下,见下图。


image.png


为了解决以上 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 过来(侵删),逗你一乐:


image.png


况且,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 "main" java.lang.Exception: close

at com.cmower.dzone.trycatchfinally.MyfinallyOutThrow.close(TryfinallyCustomOutThrow.java:17)

at com.cmower.dzone.trycatchfinally.TryfinallyCustomOutThrow.main(TryfinallyCustomOutThrow.java:10)


readLine() 方法的异常信息竟然被 close() 方法的堆栈信息吃了,这必然会让我们误以为要调查的目标是 close() 方法而不是 readLine()——尽管它也是应该怀疑的对象。


但自从有了 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() 方法。



相关文章
|
存储 缓存 弹性计算
2024年阿里云最便宜云服务器出炉:61元、165元、99元、199元
2024年截止目前阿里云最便宜的云服务器已经出炉,轻量应用服务器2核2G3M带宽61元1年、2核4G4M带宽165元1年;云服务器经济型e实例2核2G3M带宽99元1年;云服务器通用算力型u1实例2核4G5M带宽199元1年。除此之外,还有幻兽帕鲁Palworld专用服务器4核16G10M带宽只要26.52元/1个月、79.56元/3个月、149.00元/6个月,8核32G10M带宽只要90.60元/1个月、271.80元/3个月。本文为大家分享2024年阿里云最便宜的各个云服务器。
8325 4
2024年阿里云最便宜云服务器出炉:61元、165元、99元、199元
SpringCloud极简入门-Feign开启Hystrix
1.支付服务集成Hystrix 官方文档:https://cloud.spring.io/spring-cloud-static/Greenwich.SR5/single/spring-cloud.html#spring-cloud-feign-hystrix 支付服务 springcloud-pay-server-1040 之前集成了Feign,修改该工程集成Hystrix。我们除了要给Feign开启Hystrix以外还需要为Feign接口编写托底类。
370 0
|
8月前
|
编解码 安全 Android开发
如何修复 Android 和 Windows 不支持视频编解码器的问题?
视频播放时遇到“编解码器不支持”错误(如0xc00d36c4或0xc00d5212)是常见问题,即使文件格式为MP4或MKV。编解码器是编码和解码数据的工具,不同设备和版本支持不同的编解码器。解决方法包括:1) 安装所需编解码器,如K-Lite Codec Pack;2) 使用自带编解码器的第三方播放器,如VLC、KMPlayer等。这些方法能帮助你顺利播放视频。
|
10月前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
6月前
|
人工智能 自然语言处理 前端开发
从理论到实践:使用JAVA实现RAG、Agent、微调等六种常见大模型定制策略
大语言模型(LLM)在过去几年中彻底改变了自然语言处理领域,展现了在理解和生成类人文本方面的卓越能力。然而,通用LLM的开箱即用性能并不总能满足特定的业务需求或领域要求。为了将LLM更好地应用于实际场景,开发出了多种LLM定制策略。本文将深入探讨RAG(Retrieval Augmented Generation)、Agent、微调(Fine-Tuning)等六种常见的大模型定制策略,并使用JAVA进行demo处理,以期为AI资深架构师提供实践指导。
705 73
|
11月前
|
安全 Java
unsafe类和varhandle类讲解
本文介绍了Java中的Unsafe类和VarHandle类,展示了Unsafe类如何通过底层操作绕过Java的安全限制直接访问内存和对象,以及VarHandle类如何在Java 9及以上版本中提供原子性和可变性访问。
145 1
unsafe类和varhandle类讲解
|
11月前
|
存储 文字识别 算法
解析!文档扫描 SDK 中的高级图像处理技术
本博客讨论了图像质量在文档扫描中的重要性,解决了扫描过程中遇到的常见挑战,以及文档扫描 SDK 利用先进的图像处理技术来应对这些挑战。
|
Ubuntu 网络协议
ubuntu 20.4 局域网固定ip设置
【7月更文挑战第24天】
224 6
|
JSON Java 数据格式
【异常处理】关于访问swagger-ui报错java.lang.NumberFormatException: For input string: ““的解决方案总结
【异常处理】关于访问swagger-ui报错java.lang.NumberFormatException: For input string: ““的解决方案总结
912 0
|
机器学习/深度学习 人工智能 安全
使用HeyGen创建AI数字人
使用HeyGen创建AI数字人
706 4