1，unchecked Exception(不檢查異常),執行時異常，例如NullPointerException,ArrayIndexOutOfBondsException.可以編碼避免的邏輯錯誤。具體根據需要判斷是否需要捕獲，並不會在編譯期強制要求。

2,  checked Exception  可檢查異常在原始碼是必須顯示地進行捕獲處理，這是編譯期檢查的一部分。

3,  實踐經驗小結。

        a,上傳，下載不能拋異常（如果丟擲異常，程式都“斷了”，這其實是一個錯誤，哪怕下載了一個空文件也比丟擲異常強）。上傳，下載finally中必須關流。

        b,儘量不捕獲類似Exception這樣的異常，範圍太大，無法定位具體的原因。

        c,不要生吞異常。基於假設這段程式碼可能不會發生，或者感覺忽略異常是無所謂的，但是不要在產品程式碼做這樣的假設。（避免主觀意識：我覺得好像不會產生什麼異常之類的）。

        d,程式是演算法加資料結構。程式有正常的，有異常的，有錯誤的。

        e,異常不是錯誤。錯誤一般來說都是JVM不正常了。記憶體溢位錯誤，堆疊溢位錯誤。而異常更多是可控的，可能由於程式中的某些原因（邏輯，資料）造成的。可以避免，可以捕獲，但是捕獲到一定要進行處理。

4， 相對昂貴地方。

        a,try--catch，往往會影響JVM對程式碼進行優化。最好僅捕獲必要的程式碼段。

        b,利用異常控制程式碼流程，也不是一個好主意。因為遠比，if/else；switch；break;continue低效。

        c，Java每例項化一個Exception，都會對當時棧進行快照，這是一個相對比較重的操作。

5,  問題思考。

        a,服務出現反應變慢，吞吐量下降的時候，檢查發生最頻繁的Exception也是一種思路。

        b,層層丟擲異常。程式碼呼叫結構是否美觀？

6， 注意事項。

        a,一個函式儘管丟擲了多個異常，但是隻有一個異常可被傳播到呼叫段。

        b,不要在finally程式碼塊中處理返回值。

        c,如果沒有這個必要，就不要使用異常。但是又不可能不用。這是不可能的。

        d,千萬不要將異常用於控制流。

        e,異常結構程式碼與程式控制流關係。異常結構程式碼中有break,return,continue。應該如果注意這些情況發生，如果有這樣程式碼，如果準確定位錯誤（如果出現錯誤）。

7， 新概念。

        a,反應式程式設計。是非同步的，基於事件的，所以異常肯定不能直接丟擲的。如果直接丟擲，隨便一個異常引起程式崩潰，影響後續處理。