阿里P7例項講解Java異常處理
一、在 Finally 中清理資源或使用 Try-With-Resource 語句
在實際開發中會經常遇到在 try 中使用資源的情況，比如一個 InputStream ，在使用後你需要關閉它。在這種情況下，一個常見的錯誤是在 try 的尾部關閉了資源。
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);
}
}
這種情況的問題是，只要異常沒被丟擲，程式就能很好地執行。所有在 try 中的程式碼都將被正常執行，資源也會被關閉。
但是，用 try 總是有原因的。當你呼叫一個或多個可能會丟擲異常的方法或自己主動丟擲異常時，程式可能會無法到達 try 的尾部。於是在最後，資源將不被關閉。
因為，你應該將所有清理資源的程式碼放進 finally 中，或使用 try-with-resource 語句。
使用 Finally
與 try 相比，無論是 try 中的程式碼被成功執行，還是在 catch 中處理了一個異常後，Finally 中的程式碼總會被執行。因此，你可以確保所有已開啟的資源都將被關閉。
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 語句
你還可以選擇 try-with-resource 語句，在我的這篇 Java 異常處理入門 中有更為詳細的介紹。
如果你在資源中實現了 AutoCloseable 介面的話，就可以使用 try-with-resource 語句了，這也是大多數 Java 標準資源的做法。如果你在 try-with-resource 中打開了一個資源，在 try 中的程式碼被執行或異常處理後，這個資源將會被自動關閉。
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);
}
}
二、丟擲更具體的異常
你丟擲的異常越具體、越明確越好。時刻牢記這點，特別是如果有一位並不瞭解你程式碼的同事，或幾個月後的你需要呼叫自己的方法並處理異常時。
因此，你需要確保提供儘可能多的資訊，這會使得你的 API 更易於理解。這樣，呼叫你方法的人可以更好地處理異常，從而避免額外的諸如 此類的檢查 。
所以，應該找到與你的異常事件最符合的類，比如丟擲一個 NumberFormatException 而不是 IllegalArgumentException (注：例如將引數轉換為數值出錯時，應該丟擲具體的 NumberFormatException ，而不是籠統的 IllegalArgumentException )。請避免丟擲一個不具體的異常。
public void doNotDoThis() throws Exception {
...
}public void doThis() throws NumberFormatException {
...
}
三、為你的異常編寫文件
當你在方法簽名中 指定一個異常 時，你也應該在 Javadoc 中記錄它 。
所以，請確保在 Javadoc 中增加 @throws 宣告，並描述可能會導致異常的情況。
/**
* This method does something extremely useful ...
*
* @param input
* @throws MyBusinessException if ... happens
*/public void doSomething(String input) throws MyBusinessException {
...
}
四、將描述資訊與異常一同丟擲
這個方法背後的思想和前兩個是類似的。但這一次，你不必給你的方法呼叫者提供資訊。對於任何遭遇異常錯誤並需要搞清楚錯誤原因的人來說，異常資訊總是在異常出現的同時，被記錄在了日誌中，或列印在了螢幕上。
因此，請儘可能精確地描所以，最好不要在 catch 中使用 Throwable ，除非你能確保自己處於一些特定情況下，比如你自己足以處理錯誤，又或被要求處理錯誤時。述異常事件，並提供最相關的資訊以令其他人能夠理解發生了什麼異常時。
別誤會我的意思了。你沒必要去寫上一大段的文字，但你應該用一兩句簡短的話來解釋一下異常發生的原因。這能讓你的開發團隊明白問題的嚴重性，也能讓你更容易地分析服務事故。
如果你丟擲了一個特定的異常，它的類名很可能就已經描述了這是什麼型別的錯誤了。所以，你不需要提供很多額外的描述資訊。一個很好的例子是，當你提供了一個錯誤格式的 String 型別引數時，java.lang.Long 建構函式就會丟擲 NumberFormatException 。
try {
new Long("xyz");
} catch (NumberFormatException e) {
log.error(e);
}
NumberFormatException 的類名已經告訴了你問題的型別。所以異常資訊只需要返回導致問題的輸入字串就行了。如果異常類的名字不能表明其含義，那麼你還需要在異常資訊中提供必要的解釋資訊。
17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"
五、優先捕獲具體的異常
大多數 IDE 都能幫你做到這點。當你嘗試優先捕獲不那麼具體的異常時， IDE 會報告給你這是一個不能到達的程式碼塊。
這個問題的原因是隻有第一個匹配到異常的 catch 塊才會被執行。所以，如果你先 catch 了一個 IllegalArgumentException ，你將永遠無法到達處理更具體異常 NumberFormatException 的 catch 塊中，因為 NumberFormatException 是 IllegalArgumentException 的子類。
所以，請優先捕獲更具體的異常，並把不那麼具體的 catch 塊放在後面。
在下面你可以看到這樣的一個 try-catch 語句示例。第一個 catch 處理所有的 NumberFormatExceptions 異常，第二個 catch 處理 NumberFormatException 異常以外的 illegalargumentexception 異常。
public void catchMostSpecificExceptionFirst() { try {
doSomething("A message");
} catch (NumberFormatException e) { log.error(e);
} catch (IllegalArgumentException e) { log.error(e)
}
}
六、不要捕獲 Throwable
Throwable 是所有 exceptions 和 errors 的父類。雖然你可以在 catch 子句中使用它，但你應該永遠別這樣做！
如果你在 catch 子句中使用了 Throwable ，它將不僅捕獲所有異常，還會捕獲所有錯誤。這些錯誤是由 JVM 丟擲的，用來表明不打算由應用處理的嚴重錯誤。 OutOfMemoryError 和 StackOverflowError 就是典型的例子，這兩種情況都是由一些超出應用控制範圍的情況導致的，無法處理。
所以，最好不要在 catch 中使用 Throwable ，除非你能確保自己處於一些特定情況下，比如你自己足以處理錯誤，又或被要求處理錯誤。
public void doNotCatchThrowable() { try { // do something
} catch (Throwable t) { // don't do this!
}
}
七、不要忽略異常
你分析過只有用例的第一部分程式碼被執行的 bug 報告嗎？
這通常是由於忽略異常而導致的。開發者可能十分確定這個異常不會被丟擲，然後添加了一個無法處理或無法記錄這個異常的 catch 。當你找到這個 catch 時，你很可能會發現這麼一句著名的註釋： “This will never happen”。
public void doNotIgnoreExceptions() { try { // do something
} catch (NumberFormatException e) { // this will never happen
}
}
沒錯，你可能就是在分析一個永遠也不會發生的問題。
所以，請你務必不要忽略異常。你不知道程式碼在將來會經歷怎樣的改動。有些人可能會誤刪異常事件的驗證，而完全沒意識到這會產出問題。或者丟擲異常的程式碼被修改了，相同的類被丟擲了多個異常，而呼叫它們的程式碼並不能阻止這些異常發生。
你至少應該把日誌資訊打印出來，告訴那些無意識下錯誤操作的人需要檢查這裡。
public void logAnException() { try { // do something
} catch (NumberFormatException e) { log.error("This should never happen: " + e);
}
}
八、不要同時列印並丟擲異常
這可能是本文中最常被忽略的一條實踐準則了。你可以在許多程式碼片段甚至庫中發現這個問題，異常被捕獲，列印，再被重新丟擲。
try { new Long("xyz");
} catch (NumberFormatException e) { log.error(e); throw e;
}
這樣也許會很直觀地看到被列印的異常，異常再被重新丟擲，呼叫者也能很好地處理它。但這樣會使多個錯誤資訊被同個異常給打印出來。
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)
額外的資訊並不能提供更多的錯誤細節。如第4條準則中所述，異常資訊應該準確描述異常事件。 Stack Trace (堆疊追蹤)會告訴你異常在哪個類、哪個方法、哪個行中被丟擲。
如果你需要新增額外的資訊，你應該將異常捕獲幷包裝在自定義的的異常中，但要確保遵循下面的第9條實踐準則。
public void wrapException(String input) throws MyBusinessException { try { // do something
} catch (NumberFormatException e) { throw new MyBusinessException("A message that describes the error.", e);
}
}
所以，只有在你想要處理一個異常的時候才去捕獲它。否則，在方法簽名處指明這個異常讓呼叫者關注就好了。
九、包裝異常但不要丟棄原始異常
有時候將異常包裝成一個自定義異常會比捕捉一個標準異常要更好。一個典型的例子是應用或框架的特定業務異常。這允許你新增額外的資訊，也能為你的異常類實現一個特定的處理方法。
當你這麼做的時候，一定要確保原始的異常設為 cause 。 Exception 類提供了一系列的特定構造方法，這些方法可以接受 Throwable 作為引數(注：如 Exception(String message, Throwable cause) )。否則，你將會丟失原始異常的 stack trace 與資訊，這會使你分析導致異常的事件變得十分困難。
public void wrapException(String input) throws MyBusinessException { try { // do something
} catch (NumberFormatException e) { throw new MyBusinessException("A message that describes the error.", e);
}
}
總結
如你所見，當決定該丟擲還是捕獲異常時候，你需要去考慮很多方面。以上的大多數實踐準則都是為了提高你程式碼和 API 的可讀性與可用性。
異常是不僅是一個錯誤處理機制，同時也是一個溝通媒介。因此，你應該與你的同事一起討論哪些是你想要應用的最佳實踐與準則，以便所有人都能理解相關的基本概念，並用同樣的方式在實際中應用這些準則。
寫在最後：歡迎留言討論，點“關注”，不迷路，加關注，持續更新！