第一部分 選擇checked or unchecked
這里需要對異常的理解。什么算異常？java的異常處理機制是用來(lái)干什么的？異常和錯誤有什么區別？
異常機制就是java的錯誤處理機制！java中的異常意味著(zhù)2點(diǎn)：第一，讓錯誤處理代碼更有條理。這使得
正常代碼和錯誤處理代碼分離。第二，引入了context的概念，認為有些錯誤是可以被處理的。問(wèn)題就出在這兒了。
java的checked異常指的就是在當前context不能被處理的錯誤！
這句話(huà)其實(shí)是對上面2點(diǎn)的總結。首先checked異常是一種錯誤，其次這種錯誤可以被處理（或修復）。
checked異常就是可以被處理（修復）的錯誤，unchecked異常其實(shí)就是無(wú)法處理（修復）的錯誤。
說(shuō)到這兒，應該清楚了。別的語(yǔ)言沒(méi)有checked異常，就是說(shuō)它們認為錯誤都無(wú)法被修復，至少在語(yǔ)言級
不提供錯誤修復的支持。java的catch clause干的就是錯誤修復的事。
我的理解是，用好java的異常，其實(shí)就是搞清楚什么時(shí)候該用checked異常。應該把unchecked異常當作
缺省行為。unchecked異常的意思是：當我做這件事時(shí)，不可思議的情況發(fā)生了，我沒(méi)辦法正常工作下去！
然后拋出一個(gè)unchecked異常，程序掛起。而checked異常的意思是：當我做這件事時(shí)，有意外情況發(fā)生，
可以肯定的是，活是沒(méi)法干了，但是要不要掛起程序，我這個(gè)函數沒(méi)法做主，我只能匯報上級！
其實(shí)，從上面的分析可以看出，java引入checked異常只是讓程序員多了一個(gè)選擇，它并不強迫你使用checked異常。
如果你對什么時(shí)候應該使用checked異常感到迷惑，那么最簡(jiǎn)單的辦法就是，不要使用checked異常！這里包括2個(gè)方面：
第一，你自己不必創(chuàng )建新的異常類(lèi)，也不必在你的代碼中拋出checked異常，錯誤發(fā)生后只管拋出unchecked異常；
第二，對已有API的checked異常統統catch后轉為unchecked異常！
使用unchecked異常是最省事的辦法。用這種方法也可以享受“正常代碼和錯誤處理代碼分離”的好處。因為我們在調用方法時(shí)，
不用根據其返回值判斷是否有錯誤出現，只管調用，只管做正事就ok了。如果出現錯誤，程序自然會(huì )知道并掛起。這樣的效果是怎樣的呢？
第一，我們的業(yè)務(wù)代碼很清晰，基本都是在處理業(yè)務(wù)問(wèn)題，而沒(méi)有一大堆判斷是否有錯的冗余代碼。（想想看，如果沒(méi)有throw異常的機制，你只能通過(guò)函數的返回值來(lái)判斷錯誤，那么你在每個(gè)調用函數的地方都會(huì )有判斷代碼?。?br>第二，我們的代碼假設一切正常，如果確實(shí)如此，那么它工作良好。但是一旦出現任何錯誤，程序就會(huì )掛起停止運行。當然，你可以查看日志找到錯誤信息。
那么使用checked異常又是怎樣的呢？
第一，你需要考慮更多的問(wèn)題。首先在設計上就會(huì )更加復雜，其次就是代碼更加冗長(cháng)。設計上復雜體現在以下方面：
1 對異常（錯誤）的抽象和理解。你得知道什么情況才能算checked異常，使得上級確實(shí)能夠處理（修復）這種異常，并且讓整個(gè)程序從這種設計中確實(shí)得到好處。
2 對整個(gè)自定義checked異常繼承體系的設計。正如那篇文章所說(shuō)，總不能在一個(gè)方法后面拋出20個(gè)異常吧！設計自定義checked異常，就要考慮方法簽名問(wèn)題，在合適的時(shí)候拋出合適的異常（不能一味的拋出最具體的異常，也不能一味拋出最抽象的異常）
第二，業(yè)務(wù)代碼相比較使用unchecked的情況而言，不夠直接了當了。引入了throws簽名和catch clause，代碼里有很多catch，方法簽名也和異常綁定了。
第三，有了更強的錯誤處理能力。如果發(fā)生了checked異常，我們有能力處理（修復）它。表現在不是任何錯誤都會(huì )導致程序掛起，出現了checked異常，程序可能照樣運行。整個(gè)程序更加健壯，而代價(jià)就是前面2條。
第二部分 使用checked異常的最佳實(shí)踐
現在假設有些錯誤我們確定為checked異常，那么我們針對這些checked異常要怎樣編碼才合理呢？
1 不要用checked異常做流程控制。無(wú)論如何，checked異常也是一種錯誤。只是我們可以處理（修復）它而已。這種錯誤和普通業(yè)務(wù)流程還是有區別的，而且從效率上來(lái)說(shuō)，用異?？刂茦I(yè)務(wù)流程是不劃算的。其實(shí)這個(gè)問(wèn)題有時(shí)候很難界定，因為checked異常“可以修復”，那么就是說(shuō)修復后程序照常運行，這樣一來(lái)真的容易跟普通業(yè)務(wù)流程混淆不清。比如注冊用戶(hù)時(shí)用戶(hù)名已經(jīng)存在的問(wèn)題。這個(gè)時(shí)候我們要考慮，為什么要用checked異常？這和使用業(yè)務(wù)流程相比，給我帶來(lái)了什么好處？（注意checked異?？梢孕迯?，這是和unchecked異常本質(zhì)的區別）照我的理解，checked異常應該是介于正常業(yè)務(wù)流程和unchecked異常（嚴重錯誤）之間的一種比較嚴重的錯誤。出現了這種錯誤，程序無(wú)法完成正常的功能是肯定的了，但我們可以通過(guò)其他方式彌補（甚至修復），總之不會(huì )讓程序掛起就是。其實(shí)這一點(diǎn)也是設計checked異常時(shí)要考慮的問(wèn)題，也是代價(jià)之一吧。
2 對checked異常的封裝。這里面包括2個(gè)問(wèn)題：
第一，如果要創(chuàng )建新的checked異常，盡量包含多一點(diǎn)信息，如果只是一條message，那么用Exception好了。當然，用Exception會(huì )失去異常的型別信息，讓客戶(hù)端無(wú)法判斷具體型別，從而無(wú)法針對特定異常進(jìn)行處理。
第二，不要讓你要拋出的checked exception升級到較高的層次。例如，不要讓SQLException延伸到業(yè)務(wù)層。這樣可以避免方法
簽名后有太多的throws。在業(yè)務(wù)層將持久層的所有異常統統歸為業(yè)務(wù)層自定義的一種異常。
3 客戶(hù)端調用含有throws的方法要注意：
第一，不要忽略異常。既然是checked異常，catch clause里理應做些有用的事情——修復它！catch里為空白或者僅僅打印出錯信息都是不妥的！為空白就是假裝不知道甚至瞞天過(guò)海，但是，出來(lái)混遲早要還的，遲早會(huì )報unchecked異常并程序掛起！非典就是個(gè)例子。打印出錯信息也好不到哪里去，和空白相比除了多幾行信息沒(méi)啥區別。如果checked異常都被這么用，那真的不如當初都改成unchecked好了，大家都省事！
第二，不要捕獲頂層的Exception。你這么干，就是在犯罪！因為unchecked異常也是一種Exception！你把所有異常都捕獲了——不是我不相信你的能力，你根本就不知道該如何處理！這樣做的直接的后果就是，你的程序一般來(lái)說(shuō)是不會(huì )掛起了，但是出現錯誤的時(shí)候功能廢了，表面上卻看不出什么！當然，深究起來(lái)，這也不是什么罪大惡極，如果你在catch里打印了信息，這和上面那條的情況是差不多的。而這2條的共同點(diǎn)就是，沒(méi)有正確使用checked異常！費了那么大勁設計的checked異常就是給你們上級（客戶(hù)端）用的，結果你們不會(huì )用！真的不如用unchecked干脆利落了！
聯(lián)系客服
