我們在設計自己的系統或平臺時，就要考慮如何更加合理的設計異常，接下來我們就一起來看異常的設計。

一、異常概述

在程序中，異常就是程序在運行時期發生的問題，在理想的程序環境中，程序永遠不會出現問題，用戶的輸入永遠都是符合要求，邏輯沒有任何問題，要打開的文件一定存在，類型轉換一定是對的，內存一直是夠用的.....總之沒有任何問題，但是一旦出現這些描述的反面情況，如果不進行合理的處理，系統就不能正常運行，系統就無法提供正常的服務給用戶。

要處理異常就要直到異常是如何發生的，就必須要知道異常的發生原因，要知道異常發生的原因就必須知道異常發生的場景。在系統中，模塊和模塊之間的交互都可能發生異常，以JAVA為例，在程序中都是利用Method和其他模塊進行交互，那么異常的產生、拋出、聲明和處理都在Method中，如下圖就是java程序，模塊和模塊之間的交互邏輯。

如圖所示，你寫的方法和外部實體交互大概可以分為五類：

1.和資源（Resource）交互，見圖⑤處。這里資源的范圍很廣，比如進程外部的數據庫，文件，SOA服務，其他各種中間件；進程內的類，方法，線程……都算是資源。

2.給進程內的其他方法（User Method）提供服務，見圖②處。

3.依賴進程內的其他方法（Server Method），見圖③處。包括Java平臺提供的方法和其他第三方供應方提供的方法。

4.和系統環境交互，見圖⑧處。系統環境可能是直接環境——JVM，也可能是間接環境——操作系統或硬件等。

5.給外部實體提供服務，見圖①處。這種外部實體一般會通過容器（或其他類似的機制）和你的方法進行交互。

Java方法和每一類實體進行交互時，都可能發生異常。當和資源交互時，常常會因為資源不可用而發生異常，比如發生找不到文件、數據庫連接錯誤、找不到類、找不到方法……等等狀況。有可能是直接產生的，見圖⑤處；有可能是間接產生的，比如圖⑥處發生異常，Server Method把異常拋給Your Method，圖③處就間接發生了異常。一般來說，你寫的方法間接發生這類異常的可能性比直接發生要大得多，因為直接產生這類異常的方法在Java平臺中已經提供了。

異常一般具有如下特點：

（1）問題產生于外部依賴，自身邏輯和流程沒有問題。

（2）此類問題通常是暫時的，服務端及時處理可以消除，用戶可以再次使用系統服務或采取替補方案。

（3）并不影響整體流程運行。

當給Client端的方法（User Method ）提供服務時，用戶可能會傳入一些不合法的數據（或者其他不恰當的使用方法），進而影響正常流程運行。你的方法應該檢查每一個輸入數據，如果發現不合法的數據，馬上阻止執行流程，并通知用戶方法。

當調用服務方法（Server Method ）時，有可能會發生兩類異常。一類是你的使用方法不正確，導致服務中止；一類是服務方法出了異常，然后傳遞給你的方法。如果是第一種異常，你應該檢查并修改你的方法邏輯，消除BUG。對于第二類異常，你要么寫一個處理器處理，要么繼續傳遞給上層方法。

當和系統環境交互時，有可能因為JVM參數設置不當，有可能因為程序產生了大量不必要的對象，也有可能因為硬故障（操作系統或硬件出了問題），導致整個程序不可用。當這類異常發生時，最終用戶沒法選擇其他替代方案，操作到一半的數據會全部丟失。你的方法對這類異常一般沒什么辦法，既不能通過修改主流程邏輯來消除，也不能通過增加異常處理器來處理。所以通常你的方法對這類異常不需要做任何處理。但是你必須檢查進程內的所有程序和系統環境是否正常，然后協調各方，修改BUG或恢復環境。

Java的異常都是發生在方法內，所以研究Java異常，要以你設計的方法為中心。我們以“你的方法 ”為中心，總結一下處理辦法：當服務方法告訴“你的方法 ”的主流程邏輯有問題時，就要及時修復BUG來消除異常；當用戶方法非法使用“你的方法”時，應該直接中止主流程，并通知用戶方法，強迫用戶方法使用正確的方式，防止問題蔓延；當服務方法傳遞一個異常給“你的方法”時，你要判斷“你的方法”是否合適處理這個異常，如果不合適，傳遞給上層方法，如果合適，寫一個異常處理器處理這個異常。當系統環境出了問題，“你的方法”什么也做不了。

以上所述，異常有三類：

（1）檢查性異常：最具代表的檢查性異常是用戶錯誤或問題引起的異常，這是程序員無法預見的。例如要打開一個不存在文件時，一個異常就發生了，這些異常在編譯時不能被簡單地忽略。

（2）運行時異常：運行時異常是可能被程序員避免的異常。與檢查性異常相反，運行時異?？梢栽诰幾g時被忽略。

（3）錯誤：錯誤不是異常，而是脫離程序員控制的問題。錯誤在代碼中通常被忽略。例如，當棧溢出時，一個錯誤就發生了，它們在編譯也檢查不到的。

剛才以“你的方法”為中心，總結了在“你的方法”內部的處理辦法?，F在以“你”為中心，總結一下方法外部的處理方法：當資源不可用的時候，你應該協調各方，恢復資源；當發生系統故障時，你應該協調各方，恢復系統。綜上，已經基本分析清楚了異常發生的原因，以及相應的應對方法。

二、異常的好處

上面已經很清楚的闡述了什么異常，并且知道怎么使用異常，那么在程序中使用異常具體有那些好處呢？

1.好處一隔離錯誤處理代碼和常規代碼

 Exception提供了一種方法，把意外發生時的細節從程序主邏輯中隔離開來。在傳統的編程中，錯誤的檢測、報告和處理通常會導致像意大利面條那么混亂的代碼。

下面通過一組偽代碼來講解。

讀取文件正常流程是很簡單的，但是真實的運行過程中，有很多異常情況需要考慮：

（1）當文件無法打開，應該如何處理？

（2）當無法獲取文件的大小，應該如何處理？

（3）當服務器內存不足，應該如何處理？

（4）當讀取失敗，應該如何處理？

（5）當文件無法關閉，應該如何處理？

為了處理這么多異常情況，我們的做法有兩種方式，方式一通過錯誤碼來表示每一個異常發生的狀態，方式二是通過異常來表示。

為了保證流程正常進行，讀取文件需要檢測錯誤、返回狀態，原本很簡單的代碼，通過各種if/else判斷處理，代碼變得很繁瑣，代碼的可讀性變得很糟糕，如果通過第二種方式二，異常代替錯誤碼來處理正常流程，我們看看會發生什么情況？

示例如下

從上面的偽代碼可以看出，異常并沒有忽略或者代替你做readFile過程中異常情況處理，而是通過異常處理讓你的關注點更多的放在核心邏輯的處理，并且提高了代碼的可讀性。

2.好處二在調用棧中向上傳播錯誤

Exception的第二個優勢就是，傳播錯誤報告方法調用堆棧的能力。比如在一個應用流程中，readFile方法是最終被最上層得調用間接依賴，如：method1調用了method2，method2調用了method3，method3調用了readFile方法，因為readFile有很多異常情況需要處理，但是按照調用層次來看，method1是最終需要處理readFile異常錯誤碼的方法，實現方法也有兩種，方式一：逐層放回錯誤碼，直到method1接受到錯誤碼；方式二：通過逐層拋出異常，method1處理異常，其他層只關心上拋。

上面的偽代碼可以看出，最終只有method1 關心 readFile 所產生的錯誤，方式一將強制要求每個方法都關心并返回。如果有一種方式只讓關心作物的方法才關心錯誤檢測，中間環節只需要拋出異常是不是會好很多呢？方式二：就是通過調用堆棧向后搜索找到任何有興趣處理特定異常的方法

中間環節不需要關注異常的發生，只有關心異常的方法才會捕獲異常進行相應的處理。

3.好處三分組和區分錯誤類型

因為程序中拋出的所有異常都是對象，所以異常的分組或分類是類層次結構的自然結果。Java 平臺中的一組相關異常類的一個例子是在 java.io- 及其 IOException 后代中定義的異常類。IOException 是最通用的，表示執行 I / O 時可能發生的任何類型的錯誤。其后代代表更具體的錯誤。例如 FileNotFoundException 意味著文件不在磁盤上未找到

一種方法可以編寫可以處理非常特定異常的特定處理程序。FileNotFoundException 類有沒有后代， 所以下面處理器只能處理一種類型的異常。

一個方法也可以用更通用的處理器捕獲處理具體的異常。例如，為了捕獲所有的I/O異常，不管具體的類型是什么，只要給異常處理器指定一個IOException參數就行。

這個處理器可以捕獲所有的I/O異常，包括FileNotFoundException，EOFException等等。你可以通過查詢傳給異常處理器的參數，發現錯誤發生的細節。例如，用下面的代碼打印堆棧跟蹤信息：

在大多數情況下，你希望異常處理器越具體越好。理由是在你決定最佳的恢復策略之前，你首先要知道錯誤的類型。事實上，如果不捕獲具體的錯誤，這個處理器就必須要容納任何可能性。太通用的異常處理器可能會讓代碼更容易出錯，因為它們會捕獲和處理程序員意料之外的異常，這樣就超出處理器的能力范圍了。

三、J2EE核心語言中的異常

Java把異常當做是破壞正常流程的一個事件，當事件發生后，就會觸發處理機制。

Java有一套獨立的異常處理機制，在遇到異常時，方法并不返回任何值（返回值屬于正常流程），而是拋出一個封裝了錯誤信息的對象。下圖是Java異常處理機制類層級結構圖：

在 Java 中，所有的異常都有一個共同的祖先 Throwable（可拋出）。Throwable 指定代碼中可用異常傳播機制通過 Java 應用程序傳輸的任何問題的共性。Throwable：有兩個重要的子類：*Exception（異常）和 Error（錯誤）*，二者都是 Java 異常處理的重要子類，各自都包含大量子類。Error（錯誤）:是程序無法處理的錯誤，表示運行應用程序中較嚴重問題。大多數錯誤與代碼編寫者執行的操作無關，而表示代碼運行時 JVM（Java 虛擬機）出現的問題。例如，Java虛擬機運行錯誤（Virtual MachineError），當 JVM 不再有繼續執行操作所需的內存資源時，將出現 OutOfMemoryError。這些異常發生時，Java虛擬機（JVM）一般會選擇線程終止。這些錯誤表示故障發生于虛擬機自身、或者發生在虛擬機試圖執行應用時，如Java虛擬機運行錯誤（Virtual MachineError）、類定義錯誤（NoClassDefFoundError）等。這些錯誤是不可查的，因為它們在應用程序的控制和處理能力之 外，而且絕大多數是程序運行時不允許出現的狀況。對于設計合理的應用程序來說，即使確實發生了錯誤，本質上也不應該試圖去處理它所引起的異常狀況。在 Java中，錯誤通過Error的子類描述。

Exception（異常）:是程序本身可以處理的異常。Exception 類有一個重要的子類 RuntimeException。RuntimeException 類及其子類表示“JVM 常用操作”引發的錯誤。例如，若試圖使用空值對象引用、除數為零或數組越界，則分別引發運行時異常（NullPointerException、ArithmeticException）和 ArrayIndexOutOfBoundException。

通常，Java的異常(包括Exception和Error)分為可查的異常（checked exceptions）和不可查的異常（unchecked exceptions）。

運行時異常：都是RuntimeException類及其子類異常，如NullPointerException(空指針異常)、IndexOutOfBoundsException(下標越界異常)等，這些異常是不檢查異常，程序中可以選擇捕獲處理，也可以不處理。這些異常一般是由程序邏輯錯誤引起的，程序應該從邏輯角度盡可能避免這類異常的發生。運行時異常的特點是Java編譯器不會檢查它，也就是說，當程序中可能出現這類異常，即使沒有用try-catch語句捕獲它，也沒有用throws子句聲明拋出它，也會編譯通過。

非運行時異常 （編譯異常）：是RuntimeException以外的異常，類型上都屬于Exception類及其子類。從程序語法角度講是必須進行處理的異常，如果不處理，程序就不能編譯通過。如IOException、SQLException等以及用戶自定義的Exception異常，一般情況下不自定義檢查異常。

JVM字節碼分析異常處理機制

 Java異常處理的一般性建議

1.try-catch-finally 規則

（1）必須在 try 之后添加 catch 或 finally 塊。try 塊后可同時接 catch 和 finally 塊，但至少有一個塊。 

（2）必須遵循塊順序：若代碼同時使用 catch 和 finally 塊，則必須將 catch 塊放在 try 塊之后。 

（3）catch 塊與相應的異常類的類型相關。 

（4）一個 try 塊可能有多個 catch 塊。若如此，則執行第一個匹配塊。即Java虛擬機會把實際拋出的異常對象依次和各個catch代碼塊聲明的異常類型匹配，如果異常對象為某個異常類型或其子類的實例，就執行這個catch代碼塊，不會再執行其他的 catch代碼塊 

（5）可嵌套 try-catch-finally 結構。

（6）在 try-catch-finally 結構中，可重新拋出異常。 

（7）除了下列情況，總將執行 finally 做為結束：JVM 過早終止（調用 System.exit(int)）；在 finally 塊中拋出一個未處理的異常；計算機斷電、失火、或遭遇病毒攻擊。

2.Throws拋出異常的規則

如果是不可查異常（unchecked exception），即Error、RuntimeException或它們的子類，那么可以不使用throws關鍵字來聲明要拋出的異常，編譯仍能順利通過，但在運行時會被系統拋出。 

必須聲明方法可拋出的任何可查異常（checked exception）。即如果一個方法可能出現受可查異常，要么用try-catch語句捕獲，要么用throws子句聲明將它拋出，否則會導致編譯錯誤 

僅當拋出了異常，該方法的調用者才必須處理或者重新拋出該異常。當方法的調用者無力處理該異常的時候，應該繼續拋出，而不是囫圇吞棗。 

調用方法必須遵循任何可查異常的處理和聲明規則。若覆蓋一個方法，則不能聲明與覆蓋方法不同的異常。聲明的任何異常必須是被覆蓋方法所聲明異常的同類或子類。

四、異常處理和設計

下面介紹異常處理和設計注意的一些點：

1.使用異常，而不使用返回碼

關于這一點，在上面『異常的好處』有解釋。理解了這一點，程序員們才會想要使用Java異常處理機制。

2.利用運行時異常設定方法使用規則

很常見的例子就是，某個方法的參數不能為空。在實踐中，很多程序員的處理方式是，當傳入的這個參數為空的時候，就返回一個特殊值（最常見的就是返回一個null，讓用戶方法決定怎么辦）。還有的處理方式是，自己給一個默認值去兼容這種不合法參數，自己決定怎么辦。這兩種實踐都是不好的。

對于第一種處理方式，返回值是用來處理正常流程的，如果用來處理異常流程，就會讓用戶方法的正常流程變復雜。一次調用可能不明顯，當有多個連續調用就會變得很復雜了。對于第二種處理方式，看起來很強大，因為“容錯”能力看起來很強，有些程序員甚至可能會為此沾沾自喜。但是它也一樣讓正常流程變復雜了，這不是最糟糕的，最糟糕的是，你不知道下一次用戶會出什么鬼點子，傳個你現有處理代碼處理不了的東西進來。這樣你又得加代碼，繼續變復雜……BUG就是這樣產生的。

好的實踐方式就是，設定方法的使用規則，遇到不合法的使用方式時，立刻拋出一個運行時異常。這樣既不會讓主流程代碼變復雜，也不會制造不必要的BUG。為什么是運行時異常而不是檢查異常呢？這是為了強迫用戶修改代碼或者改正使用方式——這屬于用戶的使用錯誤。

3.消除運行時異常

當你的程序發生運行時異常，通常都是因為你使用別人的方法的方式不正確（如果設計這個異常的人設計錯誤，就另當別論。比如設計者捕獲一個檢查異常，然后在處理器拋出一個運行時異常給用戶。如果遇上這樣的供應商，還是棄用吧）。所以，一般都是采取修改代碼的方式，而不是新增一個異常流程。

4.正確處理檢查異常

處理檢查異常的時候，處理器一定要做到下面的要求才算合格：

（1）返回到一種安全狀態，并能夠讓用戶執行一些其他的命令；

（2）允許用戶保存所有操作的結果，并以適當的方式終止程序。

不好的實踐案例一：因為有的異常發生的概率很小，有些程序員就會寫出下面的代碼：

public Image loadImage(String s) {

     try {

          code...

     } catch (Exception e)

     {}

     code2...

}

catch代碼塊里面什么都不寫！或者只在里面打一個log。這樣既不會傳遞到上層方法，又不會報編譯錯誤，還不用動腦筋……

不好的實踐案例二：捕獲一個檢查異常，什么都不做（或只打一個log），然后拋出一個運行時異常：

public Image loadImage(String s) {

     try {

          code...

     } catch (Exception e){

          throw new RuntimeExcepiton();

     }

}

這樣也不會讓上層方法感覺到這個異常的存在，也不會報編譯錯誤了，也不用動什么腦筋……

在案例一中，一旦出現了異常，try代碼塊里的代碼沒執行完，用戶要求做的事情沒做完，卻又沒有任何反饋或者得到一個錯誤反饋。

在案例二中，一旦出現了異常，try代碼塊里的代碼沒執行完，雖然把運行時異常拋給用戶了，用戶也不會去處理這個異常，又沒有辦法通過改變使用方式消除異常，直接讓用戶代碼崩潰掉。

對于檢查異常，好的實踐方式是：

（1）讓可以處理這個異常的方法去處理。衡量的標準就是在你這個方法寫一個處理器，這個處理器能不能做到本節開頭的那兩個要求，如果不能，就往上拋。如果你不能知道所有用戶的所有需求，你通常就做不到那兩個要求。

（2）有必要的時候可以通過鏈式異常包裝一下，再拋出。

（3）最終的處理器一定要做到本節開頭的那兩個要求。

5.使主流程代碼保持整潔

一個try代碼塊后面可以跟多個catch代碼塊，這就讓一些可能會發生不同異常的代碼可以寫在一塊，讓代碼看起來很清晰。相反，在一個方法里寫多個try-catch，或者寫嵌套的try-catch，就會讓主流程代碼變得很混亂。

6.使用try-with-resources

try-with-resources語句比起普通的try語句，干凈整潔的多。而且最終拋出的異常是正常流程中拋出的異常。

7.盡量處理最具體的異常

盡量使用最具體的異常類作為處理器匹配的類型。這樣處理器就不用兼顧很多種情形，不易出錯。從Java7開始，一個處理器可以處理多種異常類型。

注意：同一個try語句中，比較具體的異常的catch代碼塊應寫在前面，比較通用的異常的catch代碼塊應寫在后面。

8.設計自己的異常類型要遵循的原則

當你是一個模塊開發者，你就很有必要設計一組或多組自己的異常類型。一般情況下，要遵守如下原則：

（1）確定什么場景下，需要創建自己的異常類型。

（2）為你的接口方法的使用規則創建一組運行時異常。

（3）封裝別人的檢查異常的時候，一定也要用檢查異常。這樣異常才能傳遞給上層方法處理。

（4）設計一組有層次結構的異常，而不是設計一堆零零散散的異常。

（5）區分清楚異常發生的原因，然后決定你的異常是檢查異常還是運行時異常。

（6）模塊內部不需要處理自己定義的異常。

五、總結

Java異常處理機制的目的至少有三個：一是歸類處理不同的異常，二是提供足夠的信息方便調試，三是讓主流程代碼保持整潔。

最后貼一張異常梳理的腦圖