【读后感】《Java编程思想》~异常

终于拿出压箱底的那本《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的异常机制可以让我们放心地编程，因为异常机制会帮我们查找出出错的位置。但是"被检查的异常"有点违背这个初衷，似乎给了一条隐藏残缺的捷径。
千万不要吞食异常，抛出来

观点不一定正确，毕竟人的认知是不断改变的，欢迎探讨和指正。