终于拿出压箱底的那本《Java 编程思想》. 这本书我年轻的时候就买了, 但是翻过几页后就放弃了. 没想到这两天翻了一下, 真的有收获.
看了一下第 12 章异常, 有两个地方令我感悟很深.
使用嵌套的 try 子句
- public static void main(String[] args) {
- try{
- InputFile in = new InputFile("Test01.java");
- try{
- String s;
- int i = 1;
- while (Objects.nonNull(s=in.getLine())){
- System.out.println(s);
- //todo
- }
- }catch (Exception e){
- System.out.println("catch exception in main");
- e.printStackTrace();
- }finally {
- in.dispose();
- }
- }catch (Exception e){
- System.out.println("construct InputFile error");
- }
- }
- }
** 处理构造可能失败, 并且需要清理的对象 **, 每个构造都必须包裹在自己的 try-finally 语句块, 并且每个对象构造器之后都必须跟随一个 try-finally 语句块, 确保自己能够被正确地清理.
上面这个就是我们工作中处理网络连接, Redis 连接, IO 文件连接的基本原型, 看似日常, 但是需要谨记 (对我而言尤其是, 毕竟有过 Redis 连接忘记释放耗尽连接池导致用户登录不进来的惨痛经历)
"被检查的异常" 是否合理
这个是在第四版的 12.12 其他可选方式 这章讲述的. 印象很深, 因为我从来没有思考过, Java 异常设计的是否合理, 没有质疑过它的正确性. 但是作者却认为,"被检查的异常" 强制程序员在没有做好准备的情况下被迫加上 catch 语句, 这个导致 "吞食则有害" 的问题. 就是说我们经常在 catch 中不处理异常或者不清楚如何处理, 错误地处理了异常, 而不是将异常抛出来.
这个问题我在项目中的代码也经常看到, 程序返回的结果不是我们想要的, 但是却没有找到异常日志, 复查代码的时候才发现, 有 catch 语句 "吞食" 了异常.
虽然代码编程规范告诉我们要抛出异常, 但是为什么一定要这么做? 期待程序员的自律, 不如不给 "吞食" 的机会.
异常设计的初衷, 我想就如作者所说, 是为了跟方便地编程, 写 C 的时候, 你不知道哪里出了问题, 只能借助调试器一步步地 debug, 但是 Java 的异常机制可以让我们放心地编程, 因为异常机制会帮我们查找出出错的位置. 但是 "被检查的异常" 有点违背这个初衷, 似乎给了一条隐藏残缺的捷径.
千万不要吞食异常, 抛出来
观点不一定正确, 毕竟人的认知是不断改变的, 欢迎探讨和指正.
来源: https://www.cnblogs.com/catlkb/p/12459602.html