前言
不管在我們的工作還是生活中，總會出現(xiàn)各種“錯誤”，各種突發(fā)的“異常”。無論我們做了多少準(zhǔn)備，多少測試，這些異常總會在某個時間點出現(xiàn)，如果處理不當(dāng)或是不及時，往往還會導(dǎo)致其他新的問題出現(xiàn)。所以我們要時刻注意這些陷阱以及需要一套“最佳實踐”來建立起一個完善的異常處理機制。
異常分類
首先，這里我畫了一個異常分類的結(jié)構(gòu)圖。
在jdk中，throwable是所有異常的父類，其下分為”error“和”exception“。error意味著出現(xiàn)了不可控的嚴(yán)重錯誤，例如outofmemoryerror。exception則細(xì)分為兩類，受檢異常（check）需要我們手動try/catch或者在方法定義中throws，編譯器在編譯的時候會檢查其合法性。非受檢異常（uncheck）則不需要我們提前處理。這些簡單的概念對于開發(fā)人員來說都是必須掌握的，這里就展示個圖例，不做詳細(xì)的描述了，我們的”正餐“還在后面。
重新認(rèn)識try/catch/finally
說到異常處理，這里就不得不提t(yī)ry/catch/finally。try不可以單獨存在，要么搭配catch，要么搭配finally，或者三者并存。
1、try代碼塊：監(jiān)視代碼塊的執(zhí)行，發(fā)現(xiàn)對應(yīng)的的異常則跳轉(zhuǎn)至catch，若無catch則直接到finally塊。
2、catch代碼塊：發(fā)生對應(yīng)的異常會執(zhí)行里面的代碼，要么處理，要么向上拋出。
3、finally代碼塊:不管是否有異常，都必執(zhí)行，一般用來清理資源，釋放連接等。然而有以下幾種情況不會執(zhí)行到這里的代碼。
- 代碼執(zhí)行流程未進(jìn)入try代碼塊。
- 代碼在try代碼塊中發(fā)生死循環(huán)、死鎖等狀態(tài)。
- 在try代碼塊中執(zhí)行了system.exit()操作。
try/catch/finally陷阱
下面介紹兩個我們在使用tcf的時候可能會遇到的陷阱。
代碼1
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public class tcfdemo { public static void main(string[] args) { //11 system.out.println(returnval()); } static int returnval(){ int a = 1; int b = 10; try{ return ++a; }finally { return ++b; } }} |
陷阱1：在finally中添加return語句，這樣會覆蓋掉try代碼return的值，假如業(yè)務(wù)邏輯比較復(fù)雜，這里是很容易掉坑的，不利于排查錯誤。
代碼2
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public class tcfdemo { public static void main(string[] args) { lock lock = new reentrantlock(); try{ //有可能加鎖失敗 lock.lock(); //dost }finally { lock.unlock(); } }} |
陷阱2：由于lock方法在加鎖的時候有可能會拋出uncheck異常，如果在try代碼塊中，必然會執(zhí)行unlock方法，此時由于并沒有加鎖成功，所以會拋出illegalmonitorstateexception，這樣一來后者的異常就覆蓋掉了前者加鎖失敗的異常信息，所以我們應(yīng)該把加鎖的方法挪至try代碼塊外面。
最佳實踐
好了，前面簡單介紹了異常的分類以及try/catch/finally的注意事項，現(xiàn)在可以總結(jié)一下我們在異常處理的時候有哪些”最佳實踐“了。
- 當(dāng)需要向上拋出異常的時候，需根據(jù)當(dāng)前業(yè)務(wù)場景定義具有業(yè)務(wù)含義的異常，優(yōu)先使用行業(yè)內(nèi)定義的異常或者團隊內(nèi)部定義好的。例如在使用dubbo進(jìn)行遠(yuǎn)程服務(wù)調(diào)用超時的時候會拋出dubbotimeoutexception，而不是直接把runtimeexception拋出。
- 請勿在finally代碼塊中使用return語句，避免返回值的判斷變得復(fù)雜。
- 捕獲異常具體的子類，而不是exception，更不是throwable。這樣會捕獲所有的錯誤，包括jvm拋出的無法處理的嚴(yán)重錯誤。
- 切記更別忽視任何一個異常（catch住了不做任何處理），即使現(xiàn)在能確保不影響邏輯的正常運行，但是對于將來誰都無法保證代碼會如何改動，別給自己挖坑。
- 不要使用異常當(dāng)作控制流程來使用，這是一個很奇葩也很影響性能的做法。
- 清理資源，釋放連接等操作一定要放在finally代碼塊中，防止內(nèi)存泄漏，如果finally塊處理的邏輯比較多且模塊化，我們可以封裝成工具方法調(diào)用，代碼會比較簡潔。
結(jié)尾
小小的異常，有大大的學(xué)問，你覺得呢？
以上所述是小編給大家介紹的java異常處理最佳實踐及陷阱防范詳解整合，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對服務(wù)器之家網(wǎng)站的支持！
原文鏈接：https://www.cnblogs.com/coding-night/p/10708750.html
