【讀後感】《Java編程思想》~ 異常

【讀後感】《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的異常機制可讓咱們放心地編程，由於異常機制會幫咱們查找出出錯的位置。可是"被檢查的異常"有點違背這個初衷，彷佛給了一條隱藏殘缺的捷徑。
千萬不要吞食異常，拋出來

觀點不必定正確，畢竟人的認知是不斷改變的，歡迎探討和指正。