Java 異常處理的 9 個(gè)最佳實(shí)踐分析
在Java中處理異常并不是一個(gè)簡(jiǎn)單的事情。不僅僅初學(xué)者很難理解，即使一些有經(jīng)驗(yàn)的開發(fā)者也需要花費(fèi)很多時(shí)間來(lái)思考如何處理異常，包括需要處理哪些異常，怎樣處理等等。這也是絕大多數(shù)開發(fā)團(tuán)隊(duì)都會(huì)制定一些規(guī)則來(lái)規(guī)范對(duì)異常的處理的原因。
無(wú)論你是新手還是資深程序員，復(fù)習(xí)下異常處理的實(shí)踐總是一件好事，因?yàn)檫@能確保你與你的團(tuán)隊(duì)在遇到問題時(shí)能夠處理得了它。
在 Java 中處理異常并不是一件易事。新手覺得處理異常難以理解，甚至是資深開發(fā)者也會(huì)花上好幾個(gè)小時(shí)來(lái)討論是應(yīng)該拋出拋異常還是處理異常。
這就是為何大多數(shù)開發(fā)團(tuán)隊(duì)都擁有一套自己的異常處理規(guī)范。如果你初進(jìn)團(tuán)隊(duì)，你也許會(huì)發(fā)現(xiàn)這些規(guī)范和你曾使用的規(guī)范大相徑庭。
盡管如此，這里還是有一些被大多數(shù)團(tuán)隊(duì)所遵循的最佳實(shí)踐準(zhǔn)則。以下9個(gè)最重要的實(shí)踐方法能幫助你開始進(jìn)行異常處理，或提高你的異常處理水平。
1、在 Finally 中清理資源或使用 Try-With-Resource 語(yǔ)句
在實(shí)際開發(fā)中會(huì)經(jīng)常遇到在 try 中使用資源的情況，比如一個(gè) InputStream ，在使用后你需要關(guān)閉它。在這種情況下，一個(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);
}
}
這種情況的問題是，只要異常沒被拋出，程序就能很好地運(yùn)行。所有在 try 中的代碼都將被正常執(zhí)行，資源也會(huì)被關(guān)閉。
但是，用 try 總是有原因的。當(dāng)你調(diào)用一個(gè)或多個(gè)可能會(huì)拋出異常的方法或自己主動(dòng)拋出異常時(shí)，程序可能會(huì)無(wú)法到達(dá) try 的尾部。于是在最后，資源將不被關(guān)閉。
因?yàn)?，你?yīng)該將所有清理資源的代碼放進(jìn) finally 中，或使用 try-with-resource 語(yǔ)句。
使用 Finally
與 try 相比，無(wú)論是 try 中的代碼被成功執(zhí)行，還是在 catch 中處理了一個(gè)異常后，F(xiàn)inally 中的代碼總會(huì)被執(zhí)行。因此，你可以確保所有已打開的資源都將被關(guān)閉。
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);
}
}
}
}
Java 7 的 Try-With-Resource 語(yǔ)句
你還可以選擇 try-with-resource 語(yǔ)句，在我的這篇Java 異常處理入門中有更為詳細(xì)的介紹。
https://stackify.com/specify-handle-exceptions-java/?utm_referrer=https%3A%2F%2Fdzone.com%2F#tryWithResource
如果你在資源中實(shí)現(xiàn)了 AutoCloseable 接口的話，就可以使用 try-with-resource 語(yǔ)句了，這也是大多數(shù) Java 標(biāo)準(zhǔn)資源的做法。如果你在 try-with-resource 中打開了一個(gè)資源，在 try 中的代碼被執(zhí)行或異常處理后，這個(gè)資源將會(huì)被自動(dòng)關(guān)閉。
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、拋出更具體的異常
你拋出的異常越具體、越明確越好。時(shí)刻牢記這點(diǎn)，特別是如果有一位并不了解你代碼的同事，或幾個(gè)月后的你需要調(diào)用自己的方法并處理異常時(shí)。
因此，你需要確保提供盡可能多的信息，這會(huì)使得你的 API 更易于理解。這樣，調(diào)用你方法的人可以更好地處理異常，從而避免額外的諸如此類的檢查。
所以，應(yīng)該找到與你的異常事件最符合的類，比如拋出一個(gè) NumberFormatException 而不是 IllegalArgumentException (注：例如將參數(shù)轉(zhuǎn)換為數(shù)值出錯(cuò)時(shí)，應(yīng)該拋出具體的 NumberFormatException ，而不是籠統(tǒng)的 IllegalArgumentException )。請(qǐng)避免拋出一個(gè)不具體的異常。
public void doNotDoThis() throws Exception {
...
}
public void doThis() throws NumberFormatException {
...
}
3、為你的異常編寫文檔
當(dāng)你在方法簽名中指定一個(gè)異常時(shí)，你也應(yīng)該在 Javadoc 中記錄它。
所以，請(qǐng)確保在 Javadoc 中增加 @throws 聲明，并描述可能會(huì)導(dǎo)致異常的情況。
/**
* This method does something extremely useful ...
*
* @param input
* @throws MyBusinessException if ... happens
*/
public void doSomething(String input) throws MyBusinessException {
...
}
4、將描述信息與異常一同拋出
這個(gè)方法背后的思想和前兩個(gè)是類似的。但這一次，你不必給你的方法調(diào)用者提供信息。對(duì)于任何遭遇異常錯(cuò)誤并需要搞清楚錯(cuò)誤原因的人來(lái)說(shuō)，異常信息總是在異常出現(xiàn)的同時(shí)，被記錄在了日志中，或打印在了屏幕上。
因此，請(qǐng)盡可能精確地描所以，最好不要在 catch 中使用 Throwable ，除非你能確保自己處于一些特定情況下，比如你自己足以處理錯(cuò)誤，又或被要求處理錯(cuò)誤時(shí)。述異常事件，并提供最相關(guān)的信息以令其他人能夠理解發(fā)生了什么異常時(shí)。
別誤會(huì)我的意思了。你沒必要去寫上一大段的文字，但你應(yīng)該用一兩句簡(jiǎn)短的話來(lái)解釋一下異常發(fā)生的原因。這能讓你的開發(fā)團(tuán)隊(duì)明白問題的嚴(yán)重性，也能讓你更容易地分析服務(wù)事故。
如果你拋出了一個(gè)特定的異常，它的類名很可能就已經(jīng)描述了這是什么類型的錯(cuò)誤了。所以，你不需要提供很多額外的描述信息。一個(gè)很好的例子是，當(dāng)你提供了一個(gè)錯(cuò)誤格式的 String 類型參數(shù)時(shí)，java.lang.Long 構(gòu)造函數(shù)就會(huì)拋出 NumberFormatException 。
try {
new Long("xyz");
} catch (NumberFormatException e) {
log.error(e);
}
NumberFormatException 的類名已經(jīng)告訴了你問題的類型。所以異常信息只需要返回導(dǎo)致問題的輸入字符串就行了。如果異常類的名字不能表明其含義，那么你還需要在異常信息中提供必要的解釋信息。
17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"
5、優(yōu)先捕獲具體的異常
大多數(shù) IDE 都能幫你做到這點(diǎn)。當(dāng)你嘗試優(yōu)先捕獲不那么具體的異常時(shí)， IDE 會(huì)報(bào)告給你這是一個(gè)不能到達(dá)的代碼塊。
這個(gè)問題的原因是只有第一個(gè)匹配到異常的 catch 塊才會(huì)被執(zhí)行。所以，如果你先 catch 了一個(gè) IllegalArgumentException ，你將永遠(yuǎn)無(wú)法到達(dá)處理更具體異常 NumberFormatException 的 catch 塊中，因?yàn)?NumberFormatException 是 IllegalArgumentException 的子類。
所以，請(qǐng)優(yōu)先捕獲更具體的異常，并把不那么具體的 catch 塊放在后面。
在下面你可以看到這樣的一個(gè) try-catch 語(yǔ)句示例。第一個(gè) catch 處理所有的 NumberFormatExceptions 異常，第二個(gè) catch 處理 NumberFormatException 異常以外的 illegalargumentexception 異常。
public void catchMostSpecificExceptionFirst() {
try {
doSomething("A message");
} catch (NumberFormatException e) {
log.error(e);
} catch (IllegalArgumentException e) {
log.error(e)
}
}
6、不要捕獲 Throwable
Throwable 是所有 exceptions 和 errors 的父類。雖然你可以在 catch 子句中使用它，但你應(yīng)該永遠(yuǎn)別這樣做!
如果你在 catch 子句中使用了 Throwable ，它將不僅捕獲所有異常，還會(huì)捕獲所有錯(cuò)誤。這些錯(cuò)誤是由 JVM 拋出的，用來(lái)表明不打算由應(yīng)用處理的嚴(yán)重錯(cuò)誤。 OutOfMemoryError 和 StackOverflowError 就是典型的例子，這兩種情況都是由一些超出應(yīng)用控制范圍的情況導(dǎo)致的，無(wú)法處理。
所以，最好不要在 catch 中使用 Throwable ，除非你能確保自己處于一些特定情況下，比如你自己足以處理錯(cuò)誤，又或被要求處理錯(cuò)誤。
public void doNotCatchThrowable() {
try {
// do something
} catch (Throwable t) {
// don't do this!
}
}
7、不要忽略異常
你分析過只有用例的第一部分代碼被執(zhí)行的 bug 報(bào)告嗎?
這通常是由于忽略異常而導(dǎo)致的。開發(fā)者可能十分確定這個(gè)異常不會(huì)被拋出，然后添加了一個(gè)無(wú)法處理或無(wú)法記錄這個(gè)異常的 catch 。當(dāng)你找到這個(gè) catch 時(shí)，你很可能會(huì)發(fā)現(xiàn)這么一句著名的注釋： “This will never happen”。
public void doNotIgnoreExceptions() {
try {
// do something
} catch (NumberFormatException e) {
// this will never happen
}
}
沒錯(cuò)，你可能就是在分析一個(gè)永遠(yuǎn)也不會(huì)發(fā)生的問題。
所以，請(qǐng)你務(wù)必不要忽略異常。你不知道代碼在將來(lái)會(huì)經(jīng)歷怎樣的改動(dòng)。有些人可能會(huì)誤刪異常事件的驗(yàn)證，而完全沒意識(shí)到這會(huì)產(chǎn)出問題。或者拋出異常的代碼被修改了，相同的類被拋出了多個(gè)異常，而調(diào)用它們的代碼并不能阻止這些異常發(fā)生。
你至少應(yīng)該把日志信息打印出來(lái)，告訴那些無(wú)意識(shí)下錯(cuò)誤操作的人需要檢查這里。
public void logAnException() {
try {
// do something
} catch (NumberFormatException e) {
log.error("This should never happen: " + e);
}
}
8、不要同時(shí)打印并拋出異常
這可能是本文中最常被忽略的一條實(shí)踐準(zhǔn)則了。你可以在許多代碼片段甚至庫(kù)中發(fā)現(xiàn)這個(gè)問題，異常被捕獲，打印，再被重新拋出。
try {
new Long("xyz");
} catch (NumberFormatException e) {
log.error(e);
throw e;
}
這樣也許會(huì)很直觀地看到被打印的異常，異常再被重新拋出，調(diào)用者也能很好地處理它。但這樣會(huì)使多個(gè)錯(cuò)誤信息被同個(gè)異常給打印出來(lái)。
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)
額外的信息并不能提供更多的錯(cuò)誤細(xì)節(jié)。如第4條準(zhǔn)則中所述，異常信息應(yīng)該準(zhǔn)確描述異常事件。 Stack Trace (堆棧追蹤)會(huì)告訴你異常在哪個(gè)類、哪個(gè)方法、哪個(gè)行中被拋出。
如果你需要添加額外的信息，你應(yīng)該將異常捕獲并包裝在自定義的的異常中，但要確保遵循下面的第9條實(shí)踐準(zhǔn)則。
public void wrapException(String input) throws MyBusinessException {
try {
// do something
} catch (NumberFormatException e) {
throw new MyBusinessException("A message that describes the error.", e);
}
}
所以，只有在你想要處理一個(gè)異常的時(shí)候才去捕獲它。否則，在方法簽名處指明這個(gè)異常讓調(diào)用者關(guān)注就好了。
9、包裝異常但不要丟棄原始異常
有時(shí)候?qū)惓０b成一個(gè)自定義異常會(huì)比捕捉一個(gè)標(biāo)準(zhǔn)異常要更好。一個(gè)典型的例子是應(yīng)用或框架的特定業(yè)務(wù)異常。這允許你添加額外的信息，也能為你的異常類實(shí)現(xiàn)一個(gè)特定的處理方法。
當(dāng)你這么做的時(shí)候，一定要確保原始的異常設(shè)為 cause 。 Exception 類提供了一系列的特定構(gòu)造方法，這些方法可以接受 Throwable 作為參數(shù)(注：如Exception(String message, Throwable cause))。否則，你將會(huì)丟失原始異常的 stack trace 與信息，這會(huì)使你分析導(dǎo)致異常的事件變得十分困難。
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í)候，你需要去考慮很多方面。以上的大多數(shù)實(shí)踐準(zhǔn)則都是為了提高你代碼和 API 的可讀性與可用性。
異常是不僅是一個(gè)錯(cuò)誤處理機(jī)制，同時(shí)也是一個(gè)溝通媒介。因此，你應(yīng)該與你的同事一起討論哪些是你想要應(yīng)用的最佳實(shí)踐與準(zhǔn)則，以便所有人都能理解相關(guān)的基本概念，并用同樣的方式在實(shí)際中應(yīng)用這些準(zhǔn)則。
下載文檔
