相關(guān)文章
國信辦再關(guān)閉31家違規網(wǎng)站 云南省2019年國家網(wǎng)絡(luò )安全周在麗江啟動(dòng)，藍隊云獲頒“最佳技術(shù)支持獎” 英特爾計劃在中國打造物聯(lián)網(wǎng)國際品牌 云南公布第二批免費向社會(huì )提供信息技術(shù)服務(wù)企業(yè)名單 中國互聯(lián)網(wǎng)企業(yè)赴美上市規模預計今年或減半
架構設計-異常處理
我們在設計自己的系統或平臺時(shí)，就要考慮如何更加合理的設計異常，接下來(lái)我們就一起來(lái)看異常的設計。
一、異常概述
在程序中，異常就是程序在運行時(shí)期發(fā)生的問(wèn)題，在理想的程序環(huán)境中，程序永遠不會(huì )出現問(wèn)題，用戶(hù)的輸入永遠都是符合要求，邏輯沒(méi)有任何問(wèn)題，要打開(kāi)的文件一定存在，類(lèi)型轉換一定是對的，內存一直是夠用的.....總之沒(méi)有任何問(wèn)題，但是一旦出現這些描述的反面情況，如果不進(jìn)行合理的處理，系統就不能正常運行，系統就無(wú)法提供正常的服務(wù)給用戶(hù)。
要處理異常就要直到異常是如何發(fā)生的，就必須要知道異常的發(fā)生原因，要知道異常發(fā)生的原因就必須知道異常發(fā)生的場(chǎng)景。在系統中，模塊和模塊之間的交互都可能發(fā)生異常，以JAVA為例，在程序中都是利用Method和其他模塊進(jìn)行交互，那么異常的產(chǎn)生、拋出、聲明和處理都在Method中，如下圖就是java程序，模塊和模塊之間的交互邏輯。
如圖所示，你寫(xiě)的方法和外部實(shí)體交互大概可以分為五類(lèi)：
1.和資源（Resource）交互，見(jiàn)圖⑤處。這里資源的范圍很廣，比如進(jìn)程外部的數據庫，文件，SOA服務(wù)，其他各種中間件；進(jìn)程內的類(lèi)，方法，線(xiàn)程……都算是資源。
2.給進(jìn)程內的其他方法（User Method）提供服務(wù)，見(jiàn)圖②處。
3.依賴(lài)進(jìn)程內的其他方法（Server Method），見(jiàn)圖③處。包括Java平臺提供的方法和其他第三方供應方提供的方法。
4.和系統環(huán)境交互，見(jiàn)圖⑧處。系統環(huán)境可能是直接環(huán)境——JVM，也可能是間接環(huán)境——操作系統或硬件等。
5.給外部實(shí)體提供服務(wù)，見(jiàn)圖①處。這種外部實(shí)體一般會(huì )通過(guò)容器（或其他類(lèi)似的機制）和你的方法進(jìn)行交互。
Java方法和每一類(lèi)實(shí)體進(jìn)行交互時(shí)，都可能發(fā)生異常。當和資源交互時(shí)，常常會(huì )因為資源不可用而發(fā)生異常，比如發(fā)生找不到文件、數據庫連接錯誤、找不到類(lèi)、找不到方法……等等狀況。有可能是直接產(chǎn)生的，見(jiàn)圖⑤處；有可能是間接產(chǎn)生的，比如圖⑥處發(fā)生異常，Server Method把異常拋給Your Method，圖③處就間接發(fā)生了異常。一般來(lái)說(shuō)，你寫(xiě)的方法間接發(fā)生這類(lèi)異常的可能性比直接發(fā)生要大得多，因為直接產(chǎn)生這類(lèi)異常的方法在Java平臺中已經(jīng)提供了。
異常一般具有如下特點(diǎn)：
（1）問(wèn)題產(chǎn)生于外部依賴(lài)，自身邏輯和流程沒(méi)有問(wèn)題。
（2）此類(lèi)問(wèn)題通常是暫時(shí)的，服務(wù)端及時(shí)處理可以消除，用戶(hù)可以再次使用系統服務(wù)或采取替補方案。
（3）并不影響整體流程運行。
當給Client端的方法（User Method ）提供服務(wù)時(shí)，用戶(hù)可能會(huì )傳入一些不合法的數據（或者其他不恰當的使用方法），進(jìn)而影響正常流程運行。你的方法應該檢查每一個(gè)輸入數據，如果發(fā)現不合法的數據，馬上阻止執行流程，并通知用戶(hù)方法。
當調用服務(wù)方法（Server Method ）時(shí)，有可能會(huì )發(fā)生兩類(lèi)異常。一類(lèi)是你的使用方法不正確，導致服務(wù)中止；一類(lèi)是服務(wù)方法出了異常，然后傳遞給你的方法。如果是第一種異常，你應該檢查并修改你的方法邏輯，消除BUG。對于第二類(lèi)異常，你要么寫(xiě)一個(gè)處理器處理，要么繼續傳遞給上層方法。
當和系統環(huán)境交互時(shí)，有可能因為JVM參數設置不當，有可能因為程序產(chǎn)生了大量不必要的對象，也有可能因為硬故障（操作系統或硬件出了問(wèn)題），導致整個(gè)程序不可用。當這類(lèi)異常發(fā)生時(shí)，最終用戶(hù)沒(méi)法選擇其他替代方案，操作到一半的數據會(huì )全部丟失。你的方法對這類(lèi)異常一般沒(méi)什么辦法，既不能通過(guò)修改主流程邏輯來(lái)消除，也不能通過(guò)增加異常處理器來(lái)處理。所以通常你的方法對這類(lèi)異常不需要做任何處理。但是你必須檢查進(jìn)程內的所有程序和系統環(huán)境是否正常，然后協(xié)調各方，修改BUG或恢復環(huán)境。
Java的異常都是發(fā)生在方法內，所以研究Java異常，要以你設計的方法為中心。我們以“你的方法 ”為中心，總結一下處理辦法：當服務(wù)方法告訴“你的方法 ”的主流程邏輯有問(wèn)題時(shí)，就要及時(shí)修復BUG來(lái)消除異常；當用戶(hù)方法非法使用“你的方法”時(shí)，應該直接中止主流程，并通知用戶(hù)方法，強迫用戶(hù)方法使用正確的方式，防止問(wèn)題蔓延；當服務(wù)方法傳遞一個(gè)異常給“你的方法”時(shí)，你要判斷“你的方法”是否合適處理這個(gè)異常，如果不合適，傳遞給上層方法，如果合適，寫(xiě)一個(gè)異常處理器處理這個(gè)異常。當系統環(huán)境出了問(wèn)題，“你的方法”什么也做不了。
以上所述，異常有三類(lèi)：
（1）檢查性異常：最具代表的檢查性異常是用戶(hù)錯誤或問(wèn)題引起的異常，這是程序員無(wú)法預見(jiàn)的。例如要打開(kāi)一個(gè)不存在文件時(shí)，一個(gè)異常就發(fā)生了，這些異常在編譯時(shí)不能被簡(jiǎn)單地忽略。
（2）運行時(shí)異常：運行時(shí)異常是可能被程序員避免的異常。與檢查性異常相反，運行時(shí)異?？梢栽诰幾g時(shí)被忽略。
（3）錯誤：錯誤不是異常，而是脫離程序員控制的問(wèn)題。錯誤在代碼中通常被忽略。例如，當棧溢出時(shí)，一個(gè)錯誤就發(fā)生了，它們在編譯也檢查不到的。
剛才以“你的方法”為中心，總結了在“你的方法”內部的處理辦法?，F在以“你”為中心，總結一下方法外部的處理方法：當資源不可用的時(shí)候，你應該協(xié)調各方，恢復資源；當發(fā)生系統故障時(shí)，你應該協(xié)調各方，恢復系統。綜上，已經(jīng)基本分析清楚了異常發(fā)生的原因，以及相應的應對方法。
二、異常的好處
上面已經(jīng)很清楚的闡述了什么異常，并且知道怎么使用異常，那么在程序中使用異常具體有那些好處呢？
1.好處一隔離錯誤處理代碼和常規代碼
Exception提供了一種方法，把意外發(fā)生時(shí)的細節從程序主邏輯中隔離開(kāi)來(lái)。在傳統的編程中，錯誤的檢測、報告和處理通常會(huì )導致像意大利面條那么混亂的代碼。
下面通過(guò)一組偽代碼來(lái)講解。
讀取文件正常流程是很簡(jiǎn)單的，但是真實(shí)的運行過(guò)程中，有很多異常情況需要考慮：
（1）當文件無(wú)法打開(kāi)，應該如何處理？
（2）當無(wú)法獲取文件的大小，應該如何處理？
（3）當服務(wù)器內存不足，應該如何處理？
（4）當讀取失敗，應該如何處理？
（5）當文件無(wú)法關(guān)閉，應該如何處理？
為了處理這么多異常情況，我們的做法有兩種方式，方式一通過(guò)錯誤碼來(lái)表示每一個(gè)異常發(fā)生的狀態(tài)，方式二是通過(guò)異常來(lái)表示。
為了保證流程正常進(jìn)行，讀取文件需要檢測錯誤、返回狀態(tài)，原本很簡(jiǎn)單的代碼，通過(guò)各種if/else判斷處理，代碼變得很繁瑣，代碼的可讀性變得很糟糕，如果通過(guò)第二種方式二，異常代替錯誤碼來(lái)處理正常流程，我們看看會(huì )發(fā)生什么情況？
示例如下
從上面的偽代碼可以看出，異常并沒(méi)有忽略或者代替你做readFile過(guò)程中異常情況處理，而是通過(guò)異常處理讓你的關(guān)注點(diǎn)更多的放在核心邏輯的處理，并且提高了代碼的可讀性。
2.好處二在調用棧中向上傳播錯誤
Exception的第二個(gè)優(yōu)勢就是，傳播錯誤報告方法調用堆棧的能力。比如在一個(gè)應用流程中，readFile方法是最終被最上層得調用間接依賴(lài)，如：method1調用了method2，method2調用了method3，method3調用了readFile方法，因為readFile有很多異常情況需要處理，但是按照調用層次來(lái)看，method1是最終需要處理readFile異常錯誤碼的方法，實(shí)現方法也有兩種，方式一：逐層放回錯誤碼，直到method1接受到錯誤碼；方式二：通過(guò)逐層拋出異常，method1處理異常，其他層只關(guān)心上拋。
上面的偽代碼可以看出，最終只有method1 關(guān)心 readFile 所產(chǎn)生的錯誤，方式一將強制要求每個(gè)方法都關(guān)心并返回。如果有一種方式只讓關(guān)心作物的方法才關(guān)心錯誤檢測，中間環(huán)節只需要拋出異常是不是會(huì )好很多呢？方式二：就是通過(guò)調用堆棧向后搜索找到任何有興趣處理特定異常的方法
中間環(huán)節不需要關(guān)注異常的發(fā)生，只有關(guān)心異常的方法才會(huì )捕獲異常進(jìn)行相應的處理。
3.好處三分組和區分錯誤類(lèi)型
因為程序中拋出的所有異常都是對象，所以異常的分組或分類(lèi)是類(lèi)層次結構的自然結果。Java 平臺中的一組相關(guān)異常類(lèi)的一個(gè)例子是在 java.io- 及其 IOException 后代中定義的異常類(lèi)。IOException 是最通用的，表示執行 I / O 時(shí)可能發(fā)生的任何類(lèi)型的錯誤。其后代代表更具體的錯誤。例如 FileNotFoundException 意味著(zhù)文件不在磁盤(pán)上未找到
一種方法可以編寫(xiě)可以處理非常特定異常的特定處理程序。FileNotFoundException 類(lèi)有沒(méi)有后代， 所以下面處理器只能處理一種類(lèi)型的異常。
一個(gè)方法也可以用更通用的處理器捕獲處理具體的異常。例如，為了捕獲所有的I/O異常，不管具體的類(lèi)型是什么，只要給異常處理器指定一個(gè)IOException參數就行。
這個(gè)處理器可以捕獲所有的I/O異常，包括FileNotFoundException，EOFException等等。你可以通過(guò)查詢(xún)傳給異常處理器的參數，發(fā)現錯誤發(fā)生的細節。例如，用下面的代碼打印堆棧跟蹤信息：
在大多數情況下，你希望異常處理器越具體越好。理由是在你決定最佳的恢復策略之前，你首先要知道錯誤的類(lèi)型。事實(shí)上，如果不捕獲具體的錯誤，這個(gè)處理器就必須要容納任何可能性。太通用的異常處理器可能會(huì )讓代碼更容易出錯，因為它們會(huì )捕獲和處理程序員意料之外的異常，這樣就超出處理器的能力范圍了。
三、J2EE核心語(yǔ)言中的異常
Java把異常當做是破壞正常流程的一個(gè)事件，當事件發(fā)生后，就會(huì )觸發(fā)處理機制。
Java有一套獨立的異常處理機制，在遇到異常時(shí)，方法并不返回任何值（返回值屬于正常流程），而是拋出一個(gè)封裝了錯誤信息的對象。下圖是Java異常處理機制類(lèi)層級結構圖：
在 Java 中，所有的異常都有一個(gè)共同的祖先 Throwable（可拋出）。Throwable 指定代碼中可用異常傳播機制通過(guò) Java 應用程序傳輸的任何問(wèn)題的共性。Throwable：有兩個(gè)重要的子類(lèi)：*Exception（異常）和 Error（錯誤）*，二者都是 Java 異常處理的重要子類(lèi)，各自都包含大量子類(lèi)。Error（錯誤）:是程序無(wú)法處理的錯誤，表示運行應用程序中較嚴重問(wèn)題。大多數錯誤與代碼編寫(xiě)者執行的操作無(wú)關(guān)，而表示代碼運行時(shí) JVM（Java 虛擬機）出現的問(wèn)題。例如，Java虛擬機運行錯誤（Virtual MachineError），當 JVM 不再有繼續執行操作所需的內存資源時(shí)，將出現 OutOfMemoryError。這些異常發(fā)生時(shí)，Java虛擬機（JVM）一般會(huì )選擇線(xiàn)程終止。這些錯誤表示故障發(fā)生于虛擬機自身、或者發(fā)生在虛擬機試圖執行應用時(shí)，如Java虛擬機運行錯誤（Virtual MachineError）、類(lèi)定義錯誤（NoClassDefFoundError）等。這些錯誤是不可查的，因為它們在應用程序的控制和處理能力之 外，而且絕大多數是程序運行時(shí)不允許出現的狀況。對于設計合理的應用程序來(lái)說(shuō)，即使確實(shí)發(fā)生了錯誤，本質(zhì)上也不應該試圖去處理它所引起的異常狀況。在 Java中，錯誤通過(guò)Error的子類(lèi)描述。
Exception（異常）:是程序本身可以處理的異常。Exception 類(lèi)有一個(gè)重要的子類(lèi) RuntimeException。RuntimeException 類(lèi)及其子類(lèi)表示“JVM 常用操作”引發(fā)的錯誤。例如，若試圖使用空值對象引用、除數為零或數組越界，則分別引發(fā)運行時(shí)異常（NullPointerException、ArithmeticException）和 ArrayIndexOutOfBoundException。
通常，Java的異常(包括Exception和Error)分為可查的異常（checked exceptions）和不可查的異常（unchecked exceptions）。
運行時(shí)異常：都是RuntimeException類(lèi)及其子類(lèi)異常，如NullPointerException(空指針異常)、IndexOutOfBoundsException(下標越界異常)等，這些異常是不檢查異常，程序中可以選擇捕獲處理，也可以不處理。這些異常一般是由程序邏輯錯誤引起的，程序應該從邏輯角度盡可能避免這類(lèi)異常的發(fā)生。運行時(shí)異常的特點(diǎn)是Java編譯器不會(huì )檢查它，也就是說(shuō)，當程序中可能出現這類(lèi)異常，即使沒(méi)有用try-catch語(yǔ)句捕獲它，也沒(méi)有用throws子句聲明拋出它，也會(huì )編譯通過(guò)。
非運行時(shí)異常 （編譯異常）：是RuntimeException以外的異常，類(lèi)型上都屬于Exception類(lèi)及其子類(lèi)。從程序語(yǔ)法角度講是必須進(jìn)行處理的異常，如果不處理，程序就不能編譯通過(guò)。如IOException、SQLException等以及用戶(hù)自定義的Exception異常，一般情況下不自定義檢查異常。
JVM字節碼分析異常處理機制
Java異常處理的一般性建議
1.try-catch-finally 規則
（1）必須在 try 之后添加 catch 或 finally 塊。try 塊后可同時(shí)接 catch 和 finally 塊，但至少有一個(gè)塊。
（2）必須遵循塊順序：若代碼同時(shí)使用 catch 和 finally 塊，則必須將 catch 塊放在 try 塊之后。
（3）catch 塊與相應的異常類(lèi)的類(lèi)型相關(guān)。
（4）一個(gè) try 塊可能有多個(gè) catch 塊。若如此，則執行第一個(gè)匹配塊。即Java虛擬機會(huì )把實(shí)際拋出的異常對象依次和各個(gè)catch代碼塊聲明的異常類(lèi)型匹配，如果異常對象為某個(gè)異常類(lèi)型或其子類(lèi)的實(shí)例，就執行這個(gè)catch代碼塊，不會(huì )再執行其他的 catch代碼塊
（5）可嵌套 try-catch-finally 結構。
（6）在 try-catch-finally 結構中，可重新拋出異常。
（7）除了下列情況，總將執行 finally 做為結束：JVM 過(guò)早終止（調用 System.exit(int)）；在 finally 塊中拋出一個(gè)未處理的異常；計算機斷電、失火、或遭遇病毒攻擊。
2.Throws拋出異常的規則
如果是不可查異常（unchecked exception），即Error、RuntimeException或它們的子類(lèi)，那么可以不使用throws關(guān)鍵字來(lái)聲明要拋出的異常，編譯仍能順利通過(guò)，但在運行時(shí)會(huì )被系統拋出。
必須聲明方法可拋出的任何可查異常（checked exception）。即如果一個(gè)方法可能出現受可查異常，要么用try-catch語(yǔ)句捕獲，要么用throws子句聲明將它拋出，否則會(huì )導致編譯錯誤
僅當拋出了異常，該方法的調用者才必須處理或者重新拋出該異常。當方法的調用者無(wú)力處理該異常的時(shí)候，應該繼續拋出，而不是囫圇吞棗。
調用方法必須遵循任何可查異常的處理和聲明規則。若覆蓋一個(gè)方法，則不能聲明與覆蓋方法不同的異常。聲明的任何異常必須是被覆蓋方法所聲明異常的同類(lèi)或子類(lèi)。
四、異常處理和設計
下面介紹異常處理和設計注意的一些點(diǎn)：
1.使用異常，而不使用返回碼
關(guān)于這一點(diǎn)，在上面『異常的好處』有解釋。理解了這一點(diǎn)，程序員們才會(huì )想要使用Java異常處理機制。
2.利用運行時(shí)異常設定方法使用規則
很常見(jiàn)的例子就是，某個(gè)方法的參數不能為空。在實(shí)踐中，很多程序員的處理方式是，當傳入的這個(gè)參數為空的時(shí)候，就返回一個(gè)特殊值（最常見(jiàn)的就是返回一個(gè)null，讓用戶(hù)方法決定怎么辦）。還有的處理方式是，自己給一個(gè)默認值去兼容這種不合法參數，自己決定怎么辦。這兩種實(shí)踐都是不好的。
對于第一種處理方式，返回值是用來(lái)處理正常流程的，如果用來(lái)處理異常流程，就會(huì )讓用戶(hù)方法的正常流程變復雜。一次調用可能不明顯，當有多個(gè)連續調用就會(huì )變得很復雜了。對于第二種處理方式，看起來(lái)很強大，因為“容錯”能力看起來(lái)很強，有些程序員甚至可能會(huì )為此沾沾自喜。但是它也一樣讓正常流程變復雜了，這不是最糟糕的，最糟糕的是，你不知道下一次用戶(hù)會(huì )出什么鬼點(diǎn)子，傳個(gè)你現有處理代碼處理不了的東西進(jìn)來(lái)。這樣你又得加代碼，繼續變復雜……BUG就是這樣產(chǎn)生的。
好的實(shí)踐方式就是，設定方法的使用規則，遇到不合法的使用方式時(shí)，立刻拋出一個(gè)運行時(shí)異常。這樣既不會(huì )讓主流程代碼變復雜，也不會(huì )制造不必要的BUG。為什么是運行時(shí)異常而不是檢查異常呢？這是為了強迫用戶(hù)修改代碼或者改正使用方式——這屬于用戶(hù)的使用錯誤。
3.消除運行時(shí)異常
當你的程序發(fā)生運行時(shí)異常，通常都是因為你使用別人的方法的方式不正確（如果設計這個(gè)異常的人設計錯誤，就另當別論。比如設計者捕獲一個(gè)檢查異常，然后在處理器拋出一個(gè)運行時(shí)異常給用戶(hù)。如果遇上這樣的供應商，還是棄用吧）。所以，一般都是采取修改代碼的方式，而不是新增一個(gè)異常流程。
4.正確處理檢查異常
處理檢查異常的時(shí)候，處理器一定要做到下面的要求才算合格：
（1）返回到一種安全狀態(tài)，并能夠讓用戶(hù)執行一些其他的命令；
（2）允許用戶(hù)保存所有操作的結果，并以適當的方式終止程序。
不好的實(shí)踐案例一：因為有的異常發(fā)生的概率很小，有些程序員就會(huì )寫(xiě)出下面的代碼：
public Image loadImage(String s) {
try {
code...
} catch (Exception e)
{}
code2...
}
catch代碼塊里面什么都不寫(xiě)！或者只在里面打一個(gè)log。這樣既不會(huì )傳遞到上層方法，又不會(huì )報編譯錯誤，還不用動(dòng)腦筋……
不好的實(shí)踐案例二：捕獲一個(gè)檢查異常，什么都不做（或只打一個(gè)log），然后拋出一個(gè)運行時(shí)異常：
public Image loadImage(String s) {
try {
code...
} catch (Exception e){
throw new RuntimeExcepiton();
}
}
這樣也不會(huì )讓上層方法感覺(jué)到這個(gè)異常的存在，也不會(huì )報編譯錯誤了，也不用動(dòng)什么腦筋……
在案例一中，一旦出現了異常，try代碼塊里的代碼沒(méi)執行完，用戶(hù)要求做的事情沒(méi)做完，卻又沒(méi)有任何反饋或者得到一個(gè)錯誤反饋。
在案例二中，一旦出現了異常，try代碼塊里的代碼沒(méi)執行完，雖然把運行時(shí)異常拋給用戶(hù)了，用戶(hù)也不會(huì )去處理這個(gè)異常，又沒(méi)有辦法通過(guò)改變使用方式消除異常，直接讓用戶(hù)代碼崩潰掉。
對于檢查異常，好的實(shí)踐方式是：
（1）讓可以處理這個(gè)異常的方法去處理。衡量的標準就是在你這個(gè)方法寫(xiě)一個(gè)處理器，這個(gè)處理器能不能做到本節開(kāi)頭的那兩個(gè)要求，如果不能，就往上拋。如果你不能知道所有用戶(hù)的所有需求，你通常就做不到那兩個(gè)要求。
（2）有必要的時(shí)候可以通過(guò)鏈式異常包裝一下，再拋出。
（3）最終的處理器一定要做到本節開(kāi)頭的那兩個(gè)要求。
5.使主流程代碼保持整潔
一個(gè)try代碼塊后面可以跟多個(gè)catch代碼塊，這就讓一些可能會(huì )發(fā)生不同異常的代碼可以寫(xiě)在一塊，讓代碼看起來(lái)很清晰。相反，在一個(gè)方法里寫(xiě)多個(gè)try-catch，或者寫(xiě)嵌套的try-catch，就會(huì )讓主流程代碼變得很混亂。
6.使用try-with-resources
try-with-resources語(yǔ)句比起普通的try語(yǔ)句，干凈整潔的多。而且最終拋出的異常是正常流程中拋出的異常。
7.盡量處理最具體的異常
盡量使用最具體的異常類(lèi)作為處理器匹配的類(lèi)型。這樣處理器就不用兼顧很多種情形，不易出錯。從Java7開(kāi)始，一個(gè)處理器可以處理多種異常類(lèi)型。
注意：同一個(gè)try語(yǔ)句中，比較具體的異常的catch代碼塊應寫(xiě)在前面，比較通用的異常的catch代碼塊應寫(xiě)在后面。
8.設計自己的異常類(lèi)型要遵循的原則
當你是一個(gè)模塊開(kāi)發(fā)者，你就很有必要設計一組或多組自己的異常類(lèi)型。一般情況下，要遵守如下原則：
（1）確定什么場(chǎng)景下，需要創(chuàng )建自己的異常類(lèi)型。
（2）為你的接口方法的使用規則創(chuàng )建一組運行時(shí)異常。
（3）封裝別人的檢查異常的時(shí)候，一定也要用檢查異常。這樣異常才能傳遞給上層方法處理。
（4）設計一組有層次結構的異常，而不是設計一堆零零散散的異常。
（5）區分清楚異常發(fā)生的原因，然后決定你的異常是檢查異常還是運行時(shí)異常。
（6）模塊內部不需要處理自己定義的異常。
五、總結
Java異常處理機制的目的至少有三個(gè)：一是歸類(lèi)處理不同的異常，二是提供足夠的信息方便調試，三是讓主流程代碼保持整潔。
最后貼一張異常梳理的腦圖
