javalang.Exception例外继承架构Error.ppt

自動嘗試關閉資源 使用自動嘗試關閉資源語法時，也可以搭配catch java.lang.AutoCloseable介面 JDK7的嘗試關閉資源語法可套用的物件，必須實作java.lang.AutoCloseable介面 java.lang.AutoCloseable介面 AutoCloseable是JDK7新增的介面，僅定義了close()方法： java.lang.AutoCloseable介面 java.lang.AutoCloseable介面 要抓還是要拋？ 父類別某個方法宣告throws某些例外，子類別重新定義該方法時可以： 不宣告throws任何例外 可throws父類別該方法中宣告的某些例外 可throws父類別該方法中宣告例外之子類別 但是不可以： throws父類別方法中未宣告的其它例外 throws父類別方法中宣告例外之父類別 貼心還是造成麻煩？ 就撰寫本書的時間點來說，Java是唯一採用受檢例外（Checked exception）的語言 文件化 提供編譯器資訊 貼心還是造成麻煩？ 有些錯誤發生引發例外時，你根本無力處理 例如使用JDBC撰寫資料庫連線程式時，經常要處理的java.sql.SQLException 假設方法是在整個應用程式非常底層被呼叫 貼心還是造成麻煩？ 為了讓例外往上浮現，你也許會選擇在每個方法呼叫上都宣告throws SQLException 這樣的作法也許會造成許多程式碼的修改（更別說要重新編譯了） 如果你根本無權修改應用程式的其他部份，這樣的作法顯然行不通。 貼心還是造成麻煩？ 受檢例外本意良好，有助於程式設計人員注意到例外的可能性並加以處理 應用程式規模增大時，會對逐漸對維護造成困難 不一定是自訂API時發生，也可能是在底層引入了一個會拋出受檢例外的API而發生類似情況。 貼心還是造成麻煩？ 重新拋出例外時，也可以考慮為應用程式自訂專屬例外類別，讓例外更能表現應用程式特有的錯誤資訊 通常建議繼承自Exception或其子類別 若不是繼承Error或RuntimeException，那麼就會是受檢例外 貼心還是造成麻煩？ 如果認為呼叫API的客戶端應當有能力處理未處理的錯誤，那就自訂受檢例外 如果認為呼叫API的客戶端沒有準備好就呼叫了方法，才會造成還有未處理的錯誤，那就自訂非受檢例外 貼心還是造成麻煩？ 一個基本的例子是這樣的： 貼心還是造成麻煩？ 如果流程中要拋出例外，也要思考一下，這是客戶端可以處理的例外嗎？還是客戶端沒有準備好前置條件就呼叫方法，才引發的例外？ 貼心還是造成麻煩？ 有些開發者在設計程式庫時，乾脆就選擇完全使用非受檢例外 選擇給予開發人員較大的彈性來面對例外（也許也需要開發人員更多的經驗） 隨著應用程式的演化，例外也可以考慮演化，也許一開始是設計為受檢例外，在經過考量後，可演化為非受檢例外 認識堆疊追蹤 認識堆疊追蹤 當例外發生而被捕捉後，可以呼叫printStackTrace()在顯示堆疊追蹤： 認識堆疊追蹤 要善用堆疊追蹤，前題是程式碼中不可有私吞例外的行為 這種程式碼會對應用程式維護造成嚴重傷害 認識堆疊追蹤 另一種對應用程式維護會有傷害的方式，就是對例外作了不適當的處理，或顯示了不正確的資訊 認識堆疊追蹤 在使用throw重拋例外時，例外的追蹤堆疊起點，仍是例外的發生根源，而不是重拋例外的地方 關於assert Java在JDK 1.4之後提供assert語法，有兩種使用的語法： boolean_expression若為true，則什麼事都不會發生，如果為false，則會發生java.lang.AssertionError 關於assert 為了避免JDK 1.3或更早版本程式使用assert作為變數導致名稱衝突問題，預設執行時不啟動斷言檢查 如果要在執行時啟動斷言檢查，可以在執行java指令時，指定-enableassertions或是-ea引數 關於assert 斷言客戶端呼叫方法前，已經準備好某些前置條件（通常在private方法之中） 斷言客戶端呼叫方法後，具有方法承諾的結果 斷言物件某個時間點下的狀態 使用斷言取代註解 斷言程式流程中絕對不會執行到的程式碼部份 關於assert 以第5章的CashCard物件為例 關於assert 關於assert 控制流程不變量（Control flow invariant）判斷 使用finally 何時關閉資源呢？ 使用finally finally區塊一定會被執行 使用finally 如果程式撰寫的流程中先return了，而且也有寫finally區塊，那finally區塊會先執行完後，再將值傳回 自動嘗試關閉資源 在JDK7之後，新增了