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

• 2020 年 3 月 10 日
• 筆記

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

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