Java 處理 Exception 的 9 個(gè)最佳實(shí)踐!
原文: https://dzone.com/articles/9-best-practices-to-handle-exceptions-in-java?
譯者：颯然Hang
譯文：http://www.rowkey.me/blog/2017/09/17/java-exception/
在Java中處理異常并不是一個(gè)簡單的事情。不僅僅初學(xué)者很難理解，即使一些有經(jīng)驗(yàn)的開發(fā)者也需要花費(fèi)很多時(shí)間來思考如何處理異常，包括需要處理哪些異常，怎樣處理等等。這也是絕大多數(shù)開發(fā)團(tuán)隊(duì)都會(huì)制定一些規(guī)則來規(guī)范對(duì)異常的處理的原因。而團(tuán)隊(duì)之間的這些規(guī)范往往是截然不同的。
本文給出幾個(gè)被很多團(tuán)隊(duì)使用的異常處理最佳實(shí)踐。
1. 在Finally塊中清理資源或者使用try-with-resource語句
當(dāng)使用類似InputStream這種需要使用后關(guān)閉的資源時(shí)，一個(gè)常見的錯(cuò)誤就是在try塊的最后關(guān)閉資源。
public void doNotCloseResourceInTry() {
FileInputStream inputStream = null;
try {
File file = new File("./tmp.txt");
inputStream = new FileInputStream(file);
// use the inputStream to read a file
// do NOT do this
inputStream.close();
} catch (FileNotFoundException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
上述代碼在沒有任何exception的時(shí)候運(yùn)行是沒有問題的。但是當(dāng)try塊中的語句拋出異?；蛘咦约簩?shí)現(xiàn)的代碼拋出異常，那么就不會(huì)執(zhí)行最后的關(guān)閉語句，從而資源也無法釋放。
合理的做法則是將所有清理的代碼都放到finally塊中或者使用try-with-resource語句。
public void closeResourceInFinally() {
FileInputStream inputStream = null;
try {
File file = new File("./tmp.txt");
inputStream = new FileInputStream(file);
// use the inputStream to read a file
} catch (FileNotFoundException e) {
log.error(e);
} finally {
if (inputStream != null) {
try {
inputStream.close();
} catch (IOException e) {
log.error(e);
}
}
}
}
public void automaticallyCloseResource() {
File file = new File("./tmp.txt");
try (FileInputStream inputStream = new FileInputStream(file);) {
// use the inputStream to read a file
} catch (FileNotFoundException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}
2. 指定具體的異常
盡可能的使用最具體的異常來聲明方法，這樣才能使得代碼更容易理解。
public void doNotDoThis() throws Exception {
...
}
public void doThis() throws NumberFormatException {
...
}
如上，NumberFormatException字面上即可以看出是數(shù)字格式化錯(cuò)誤。
3. 對(duì)異常進(jìn)行文檔說明
當(dāng)在方法上聲明拋出異常時(shí)，也需要進(jìn)行文檔說明。和前面的一點(diǎn)一樣，都是為了給調(diào)用者提供盡可能多的信息，從而可以更好地避免/處理異常。異常處理的 10 個(gè)最佳實(shí)踐，這篇也推薦看下。
在Javadoc中加入throws聲明，并且描述拋出異常的場景。
/**
* This method does something extremely useful ...
*
* @param input
* @throws MyBusinessException if ... happens
*/
public void doSomething(String input) throws MyBusinessException {
...
}
4. 拋出異常的時(shí)候包含描述信息
在拋出異常時(shí)，需要盡可能精確地描述問題和相關(guān)信息，這樣無論是打印到日志中還是監(jiān)控工具中，都能夠更容易被人閱讀，從而可以更好地定位具體錯(cuò)誤信息、錯(cuò)誤的嚴(yán)重程度等。
但這里并不是說要對(duì)錯(cuò)誤信息長篇大論，因?yàn)楸緛鞥xception的類名就能夠反映錯(cuò)誤的原因，因此只需要用一到兩句話描述即可。
try {
new Long("xyz");
} catch (NumberFormatException e) {
log.error(e);
}
NumberFormatException即告訴了這個(gè)異常是格式化錯(cuò)誤，異常的額外信息只需要提供這個(gè)錯(cuò)誤字符串即可。當(dāng)異常的名稱不夠明顯的時(shí)候，則需要提供盡可能具體的錯(cuò)誤信息。
5. 首先捕獲最具體的異常
現(xiàn)在很多IDE都能智能提示這個(gè)最佳實(shí)踐，當(dāng)你試圖首先捕獲最籠統(tǒng)的異常時(shí)，會(huì)提示不能達(dá)到的代碼。當(dāng)有多個(gè)catch塊中，按照捕獲順序只有第一個(gè)匹配到的catch塊才能執(zhí)行。因此，如果先捕獲IllegalArgumentException，那么則無法運(yùn)行到對(duì)NumberFormatException的捕獲。
public void catchMostSpecificExceptionFirst() {
try {
doSomething("A message");
} catch (NumberFormatException e) {
log.error(e);
} catch (IllegalArgumentException e) {
log.error(e)
}
}
6. 不要捕獲Throwable
Throwable是所有異常和錯(cuò)誤的父類。你可以在catch語句中捕獲，但是永遠(yuǎn)不要這么做。如果catch了throwable，那么不僅僅會(huì)捕獲所有exception，還會(huì)捕獲error。而error是表明無法恢復(fù)的jvm錯(cuò)誤。因此除非絕對(duì)肯定能夠處理或者被要求處理error，不要捕獲throwable。
public void doNotCatchThrowable() {
try {
// do something
} catch (Throwable t) {
// don't do this!
}
}
7. 不要忽略異常
很多時(shí)候，開發(fā)者很有自信不會(huì)拋出異常，因此寫了一個(gè)catch塊，但是沒有做任何處理或者記錄日志。
public void doNotIgnoreExceptions() {
try {
// do something
} catch (NumberFormatException e) {
// this will never happen
}
}
但現(xiàn)實(shí)是經(jīng)常會(huì)出現(xiàn)無法預(yù)料的異?；蛘邿o法確定這里的代碼未來是不是會(huì)改動(dòng)(刪除了阻止異常拋出的代碼)，而此時(shí)由于異常被捕獲，使得無法拿到足夠的錯(cuò)誤信息來定位問題。合理的做法是至少要記錄異常的信息。
public void logAnException() {
try {
// do something
} catch (NumberFormatException e) {
log.error("This should never happen: " + e);
}
}
8. 不要記錄并拋出異常
可以發(fā)現(xiàn)很多代碼甚至類庫中都會(huì)有捕獲異常、記錄日志并再次拋出的邏輯。如下：
try {
new Long("xyz");
} catch (NumberFormatException e) {
log.error(e);
throw e;
}
這個(gè)處理邏輯看著是合理的。但這經(jīng)常會(huì)給同一個(gè)異常輸出多條日志。如下：
17:44:28,945 ERROR TestExceptionHandling:65 - java.lang.NumberFormatException: For input string: "xyz"
Exception in thread "main" java.lang.NumberFormatException: For input string: "xyz"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:589)
at java.lang.Long.(Long.java:965)
at com.stackify.example.TestExceptionHandling.logAndThrowException(TestExceptionHandling.java:63)
at com.stackify.example.TestExceptionHandling.main(TestExceptionHandling.java:58)
如上所示，后面的日志也沒有附加更有用的信息。如果想要提供更加有用的信息，那么可以將異常包裝為自定義異常。
public void wrapException(String input) throws MyBusinessException {
try {
// do something
} catch (NumberFormatException e) {
throw new MyBusinessException("A message that describes the error.", e);
}
}
因此，僅僅當(dāng)想要處理異常時(shí)才去捕獲，否則只需要在方法簽名中聲明讓調(diào)用者去處理。
9. 包裝異常時(shí)不要拋棄原始的異常
捕獲標(biāo)準(zhǔn)異常并包裝為自定義異常是一個(gè)很常見的做法。這樣可以添加更為具體的異常信息并能夠做針對(duì)的異常處理。
需要注意的是，包裝異常時(shí)，一定要把原始的異常設(shè)置為cause(Exception有構(gòu)造方法可以傳入cause)。否則，丟失了原始的異常信息會(huì)讓錯(cuò)誤的分析變得困難。
public void wrapException(String input) throws MyBusinessException {
try {
// do something
} catch (NumberFormatException e) {
throw new MyBusinessException("A message that describes the error.", e);
}
}
總結(jié)
綜上可知，當(dāng)拋出或者捕獲異常時(shí)，有很多不一樣的東西需要考慮。其中的許多點(diǎn)都是為了提升代碼的可閱讀性或者api的可用性。異常不僅僅是一個(gè)錯(cuò)誤控制機(jī)制，也是一個(gè)溝通媒介，因此與你的協(xié)作者討論這些最佳實(shí)踐并制定一些規(guī)范能夠讓每個(gè)人都理解相關(guān)的通用概念并且能夠按照同樣的方式使用它們。
文末福利：我總結(jié)了一套 5000 頁的 Java 學(xué)習(xí)手冊(cè)，在知乎已經(jīng)3萬贊了！此手冊(cè)內(nèi)容專注 Java技術(shù)，包括 JavaWeb，SSM，Linux，Spring Boot，MyBatis，MySQL，Nginx，Git，GitHub，Servlet，IDEA，多線程，集合，JVM，DeBug, Dubbo，Redis，算法，面試題等相關(guān)內(nèi)容。
下載方式
1.?首先掃描下方二維碼
2.?后臺(tái)回復(fù)「555」即可獲取
注明：僅僅作為知識(shí)分享，切勿用于其它商業(yè)活動(dòng) 。感謝所有技術(shù)分享者的付出。
點(diǎn)贊是最大的支持?