資訊專欄INFORMATION COLUMN
摘要：異常處理的個最佳實踐原文地址翻譯出處在中，異常處理是個很麻煩的事情。使用描述性消息拋出異常這個最佳實踐背后的想法與前兩個類似。當你以錯誤的格式提供時，它將被類的構造函數拋出。類提供了特殊的構造函數方法，它接受一個作為參數。
Java 異常處理的 9 個最佳實踐
原文地址：https://dzone.com/articles/9-...翻譯出處：https://www.oschina.net/trans...
在 Java 中，異常處理是個很麻煩的事情。初學者覺得它很難理解，甚至是經驗豐富的開發者也要花費很長時間決定異常是要處理掉和拋出。
所以很多開發團隊約定一些原則處理異常。如果你是一個團隊的新成員，你可能會很驚訝，因為他們約定的規則可能和你以前使用的規則不一樣。
不過，有很多最佳實踐的規則，被大部分團隊接受。這里有 9 大重要的約定，幫助你學習或者改進異常處理。
1、在 Finally 清理資源或者使用 Try-With-Resource 特性大部分情況下，在 try 代碼塊中使用資源后需要關閉資源，例如 InputStream 。在這些情況下，一種常見的失誤就是在 try 代碼塊的最后關閉資源。
問題就是，只有沒有異常拋出的時候，這段代碼才可以正常工作。try 代碼塊內代碼會正常執行，并且資源可以正常關閉。但是，使用 try 代碼塊是有原因的，一般調用一個或多個可能拋出異常的方法，而且，你自己也可能會拋出一個異常，這意味著代碼可能不會執行到 try 代碼塊的最后部分。結果就是，你并沒有關閉資源。
所以，你應該把清理工作的代碼放到 finally 里去，或者使用 try-with-resource 特性。
使用 Finally 代碼塊
與前面幾行 try 代碼塊不同，finally 代碼塊總是會被執行。不管 try 代碼塊成功執行之后還是你在 catch 代碼塊中處理完異常后都會執行。因此，你可以確保你清理了所有打開的資源。
Java 7 的 Try-With-Resource 語法
另一個可選的方案是 try-with-resource 語法，我在介紹 Java 的異常處理里更詳細的介紹了它。
如果你的資源實現了 AutoCloseable 接口，你可以使用這個語法。大多數的 Java 標準資源都繼承了這個接口。當你在 try 子句中打開資源，資源會在 try 代碼塊執行后或異常處理后自動關閉。
2、優先明確異常你拋出的異常越明確越好，永遠記住，你的同事或者幾個月之后的你，將會調用你的方法并且處理異常。
因此需要保證提供給他們盡可能多的信息。這樣你的 API 更容易被理解。你的方法的調用者能夠更好的處理異常并且避免額外的檢查。
因此，總是嘗試尋找最適合你的異常事件的類，例如，拋出一個 NumberFormatException 來替換一個 IllegalArgumentException 。避免拋出一個不明確的異常。
3、記錄指定的異常每當你在方法簽名中指定異常，你也應該在 Javadoc 中記錄它。 這與上一個最佳實踐具有相同的目標：盡可能多地向調用者提供信息，以便避免或處理異常。
因此，請確保向 Javadoc 添加 @throws 聲明并描述可能導致異常的情況。
4、使用描述性消息拋出異常這個最佳實踐背后的想法與前兩個類似。但這一次，你不會將信息提供給方法的調用者。每個必須了解在日志文件或監視工具中報告異常情況時發生了什么情況的人都可以讀取異常消息。
因此，應該盡可能精確地描述問題，并提供最相關的信息來了解異常事件。
不要誤會我的意思，你不用去寫一段文字。但你也應該在1-2個短句中解釋異常的原因。這有助于你的運營團隊了解問題的嚴重性，并且還可以讓你更輕松地分析任何服務突發事件。
如果拋出一個特定的異常，它的類名很可能已經描述了這種錯誤。所以，你不需要提供很多額外的信息。一個很好的例子是 NumberFormatException 。當你以錯誤的格式提供 String 時，它將被 java.lang.Long 類的構造函數拋出。
NumberFormatException 類的名稱已經告訴你這種問題。它的消息表示只需要提供導致問題的輸入字符串。如果異常類的名稱不具有表達性，則需要在消息中提供所需的信息。
17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"
5、優先捕獲最具體的異常大多數 IDE 都可以幫助你實現這個最佳實踐。當你嘗試首先捕獲較不具體的異常時，它們會報告無法訪問的代碼塊。
但問題在于，只有匹配異常的第一個 catch 塊會被執行。 因此，如果首先捕獲 IllegalArgumentException ，則永遠不會到達應該處理更具體的 NumberFormatException 的 catch 塊，因為它是 IllegalArgumentException 的子類。
總是優先捕獲最具體的異常類，并將不太具體的 catch 塊添加到列表的末尾。
你可以在下面的代碼片斷中看到這樣一個 try-catch 語句的例子。 第一個 catch 塊處理所有 NumberFormatException 異常，第二個處理所有非 NumberFormatException 異常的 IllegalArgumentException 異常。
6、不要捕獲 Throwable 類Throwable 是所有異常和錯誤的超類。你可以在 catch 子句中使用它，但是你永遠不應該這樣做！
如果在 catch 子句中使用 Throwable ，它不僅會捕獲所有異常，也將捕獲所有的錯誤。JVM 拋出錯誤，指出不應該由應用程序處理的嚴重問題。 典型的例子是 OutOfMemoryError 或者 StackOverflowError 。 兩者都是由應用程序控制之外的情況引起的，無法處理。
所以，最好不要捕獲 Throwable ，除非你確定自己處于一種特殊的情況下能夠處理錯誤。
7、不要忽略異常你曾經有去分析過一個只執行了你用例的第一部分的 bug 報告嗎？
這通常是由于一個被忽略的異常造成的。開發者可能會非常肯定，它永遠不會被拋出，并添加一個 catch 塊，不做處理或不記錄它。而當你發現這個塊時，你很可能甚至會發現其中有一個“這永遠不會發生”的注釋。
那么，你可能正在分析一個不可能發生的問題。
所以，請不要忽略任何一個異常。 你不知道代碼將來如何改變。有人可能會在沒有意識到會造成問題的情況下，刪除阻止異常事件的驗證。或者是拋出異常的代碼被改變，現在拋出同一個類的多個異常，而調用的代碼并不能阻止所有異常。
你至少應該寫一條日志信息，告訴大家這個不可思議的事發生了，而且有人需要檢查它。
8、不要記錄日志和拋出錯誤這可能是該文章中最常被忽略的最佳實踐。 你可以找到很多的其中有一個異常被捕獲的代碼片段，甚至是一些代碼庫，被記錄和重新拋出。
在發生異常時記錄異常可能會感覺很直觀，然后重新拋出異常，以便調用者可以適當地處理異常。但它會為同一個異常重復寫入多個錯誤消息。
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中所解釋的那樣，異常消息應該描述異常事件。 堆棧跟蹤告訴你在哪個類，方法和行中拋出異常。
如果你需要添加其他信息，則應該捕獲異常并將其包裝在自定義的信息中。 但請務必遵循最佳實踐9。
所以，只捕獲你想處理的異常。 否則，在方法簽名中指定它，并讓調用者處理它。
9、封裝好的異常類而不使用有時候，最好是捕獲一個標準異常并將其封裝成一定制的異常。一個典型的例子是應用程序或框架特定的業務異常。允許你添加些額外的信息，并且你也可以為你的異常類實現一個特殊的處理。
在你這樣做時，請確保將原始異常設置為原因（注：參考下方代碼 NumberFormatException e 中的原始異常 e ）。Exception 類提供了特殊的構造函數方法，它接受一個 Throwable 作為參數。另外，你將會丟失堆棧跟蹤和原始異常的消息，這將會使分析導致異常的異常事件變得困難。
總結
如你所見，當你拋出或捕獲異常的時候，有很多不同的事情需要考慮，而且大部分事情都是為了改善代碼的可讀性或者 API 的可用性。
異常通常都是一種異常處理技巧，同時也是一種通信媒介。因此，為了和同事更好的合作，一個團隊必須要制定出一個最佳實踐和規則，只有這樣團隊成員才能理解這些通用概念，同時在工作中使用它。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/70960.html
摘要：為可恢復的錯誤使用檢查型異常，為編程錯誤使用非檢查型錯誤。檢查型異常保證你對錯誤條件提供異常處理代碼，這是一種從語言到強制你編寫健壯的代碼的一種方式，但同時會引入大量雜亂的代碼并導致其不可讀。在編程中選擇檢查型異常還是運行時異常。 異常處理是Java 開發中的一個重要部分。它是關乎每個應用的一個非功能性需求，是為了處理任何錯誤狀況，比如資源不可訪問，非法輸入，空輸入等等。Java提供了...
摘要：兩個字符串拼接直接調用性能最好。關于的其他最佳實踐用時總是把能確定不為空的變量寫在左邊，如使用判斷空串，避免空指針異常。在需要把其他對象轉換為字符串對象時，使用而不是直接調用方法，因為前者已經對空值進行檢測了，不會拋出空指針異常。 本文來源于問題 Java字符串連接最佳實踐？ java連接字符串有多種方式，比如+操作符，StringBuilder.append方法，這些方法各有什么優...
摘要：然而，我更傾向于使用來單元測試來文檔化異常。單元測試允許我在使用中查看異常，并且作為一個可以被執行的文檔來使用。通過為異常編寫單元測試，你不僅可以記錄異常如何觸發，還可以使你的代碼在經過這些測試后更加健壯。 本文是關于 Exception 處理的一篇不錯的文章，從 Java Exception 的概念介紹起，依次講解了 Exception 的類型(Checked/Unchecked)，...
摘要：無需檢查的異常也是的子類。從低層拋出的需檢查異常強制要求調用方捕獲或是拋出該異常。當前執行的線程將會停止并報告該異常。單元測試允許我在使用中查看異常，并且作為一個可以被執行的文檔來使用。不要捕獲最高層異常繼承的異常同樣是的子類。 前言 異常處理的問題之一是知道何時以及如何去使用它。我會討論一些異常處理的最佳實踐，也會總結最近在異常處理上的一些爭論。 作為程序員，我們想要寫高質量的能夠解...
摘要：不相等的對象要具有不相等的哈希碼為了哈希表的操作效率，這一點很重要，但不是強制要求，最低要求是不相等的對象不能共用一個哈希碼。方法和方法協同工作，返回對象的哈希碼。這個哈希碼基于對象的身份生成，而不是對象的相等性。 本文面向 剛學完Java的新手們。這篇文章不講語法，而是一些除了語法必須了解的概念。 將要去面試的初級工程師們。查漏補缺，以免遭遇不測。 目前由于篇幅而被挪出本文的知識...
閱讀 3158·2021-10-14 09:42
閱讀 3564·2019-08-26 13:56
閱讀 3443·2019-08-26 11:59
閱讀 938·2019-08-23 18:00
閱讀 2195·2019-08-23 17:51
閱讀 3522·2019-08-23 17:17
閱讀 1478·2019-08-23 15:11
閱讀 5145·2019-08-23 15:05
