忽略異常

Github和Sourceforge上超過600,000個Java項目中的異常處理概述

Java是使用檢查異常的少數幾種語言之一。 它們在編譯時強制執行，并且需要某種處理。 但是……在實踐中會發生什么？ 大多數開發人員實際上會處理任何事情嗎？ 他們怎么做到的？

在這篇文章中，我們將介紹滑鐵盧大學最近的一項研究數據，該數據涵蓋了來自GitHub和sourceforge的600,000多個Java項目中的異常使用。 讓我們深入探討并回答一些問題。

catch子句中的十大異常類型

嗯，聽起來很熟悉？ 最近，我們根據生產中1,000多個應用程序中的數據進行了數據緊縮后發布了結果 ，在其中我們檢查了拋出的前10種異常類型。

在這種數據緊縮的情況下，研究人員分析了Github和Sourceforge上的Java項目，調查了catch子句并報告了發現的結果。 讓我們看看數據集的樣子：

catch子句中排名前10位的異常類型，來源：“ Java異常處理模式分析”

好吧，我們在這里有什么？ 研究發現，在Java項目中，檢查異常占未檢查異常數量的幾乎三倍。 不能在這里打亂編譯器。 在生產數據緊縮中 ，我們看到了相反的結果，其中未檢查最高例外。

這里要注意的一個重要區別是，生產緊縮考慮了拋出類型，而本研究指的是捕獲類型，它可能與拋出對象不同/更高級別。

另一個見解是，開發人員經常使用Throwable和Exception類在頂級捕獲已檢查的異常。 情節變濃了 。

為了了解有關如何處理已檢查的異常的更多信息，研究人員檢查了Exception和Throwable處理程序。 捕獲Exception的78％的方法未捕獲其任何子類，與Throwable的84％相同。 毫無意義的catch子句。

接下來，讓我們找出這些catch子句中發生了什么。 也許有希望。

“大多數程序員會忽略檢查的異常，而不會引起注意”

聽起來不好嗎？ 繼續閱讀。 這是研究的真實，真實，正式內容。 我們中的許多人對被檢查的異常有一種刺痛的蜘蛛般的感覺，但是在軟件開發中，很少有數據能夠為圍繞實際代碼樣式的問題提供冷硬證明。 除了個人經驗和定性研究而不是定量研究。

下表顯示了在前3個檢查的異常捕獲塊中執行的前幾個操作：

選中的異常捕獲子句中的頂級操作，來源：“ Java異常處理模式分析”

我們看到日志語句和e.printStackTrace（）在頂部，使它們成為檢查異常捕獲塊中使用的頂部操作，這有助于調試情況并了解發生了什么。

臭名昭著的空漁獲量吸引了他們。 Joshua Bloch在“ Effective Java”中描述了理想的情況：“為了捕獲故障，異常的詳細信息應包含促成異常的所有參數和字段的值”。 空的捕獲塊正在克服這個目的。

另一個常見用例是引發未檢查的異常，該異常將替換已檢查的異常。

Mario Fusco在他的Twitter提要上總結得很好：

Java開發人員在受檢查的異常捕獲塊中所做的事情表明，如果您強迫開發人員執行不必要的smtg，則他將使smtg變得愚蠢

— Mario Fusco（@mariofusco） 2016年6月6日

但是等等，還有更多

從檢查異常和未檢查異常的整體情況來看，這一次僅在Github上，我們看到類似的情況，重新引發獲得了更多的歡迎：

異常處理（Github）中使用的頂級操作，來源：“ Java異常處理模式分析”

總計（6,172,462）個捕獲塊中有20％為空。 這是很糟糕的。 將點與以下事實聯系起來：在層次結構中較高級別的異常比特定類型使用的頻率更高，研究人員得出的結論是：“大多數參與者似乎將異常處理作為一項任務給予了較低的優先級，或者將異常包括在他們的任務中。僅在該語言迫使他們處理檢查的異常時才進行編碼。”

最終，產品質量受損。

重新拋出是怎么回事？

由于在調用堆棧層次結構中引發異常是最流行的catch子句操作，因此研究人員進一步研究了哪種轉換最為流行。 下表中匯總了結果：

頂級異常轉換，來源：來源：“ Java異常處理模式分析”

在＃1中，將Exception轉換為RuntimeException。 從任何異常類型進行的大多數轉換都轉換為RuntimeException，從而使未檢查的異常變為選中狀態。

例外最佳實踐

除了數據緊縮及其洞察力之外，本文還提到了約書亞·布洛赫（Joshua Bloch）處理其著名的第二版《有效Java》中的異常的準則（第9章）。 我們認為在此處列出它們也是一個好主意：

1.“僅在例外情況下使用例外”

異常在JVM上造成相當大的開銷，將異常用于常規流控制是造成麻煩的原因（是的，即使許多開發人員濫用了它）。 在可執行的例外情況帖子中 ，我們詳細介紹了此“常規例外情況”問題。

2.“將檢查的異常用于可恢復的條件，將運行時異常用于編程錯誤”

這意味著，如果開發人員發現檢查后的異常不可恢復，則可以將其狀態包裝在未經檢查的異常中，然后將其拋出層次結構以進行日志記錄和處理。

3.“避免不必要地使用檢查的異常”

僅當通過正確地編碼API無法避免異常并且沒有替代恢復步驟時，才使用檢查的異常。

4.“善用標準例外”

使用已經廣泛的Java API中的標準異常可提高可讀性。

5.“拋出適合抽象的異常”

在層次結構中前進時，請使用適當的異常類型。

6.“記錄每種方法引發的所有異常”

當涉及異常時，沒有人會喜歡驚喜。

7.“在詳細消息中包含故障捕獲信息”

沒有有關JVM所處狀態的信息，您無法做很多事情來確保不再發生該異常。 并不是每個人都有Takipi掩蓋他們的背部。

8.“不要忽略異常”

所有異常都應導致某種行為，您還需要它們做什么？

要了解有關這些準則的更多信息，請查看上一篇有關可操作異常的博客文章 ，以及最近一次涵蓋1000多個生產應用程序的生產數據緊縮的教訓，以了解其日志中的內容以及遇到的十大異常 。

我們到底在看什么呢？

這項研究的數據來自加拿大安大略省滑鐵盧大學的David R. Cheriton計算機科學學院的Suman Nakshatri ， Maithri Hegde和Sahithi Thandra的研究論文 。

研究人員研究了780萬個Github項目和70萬個Sourceforge項目的數據庫 ，提取了Java項目，并檢查了BOA領域特定語言對catch塊在采礦軟件存儲庫中的使用情況。

數據集由數字

最后的想法

例外情況應保留給例外情況，但是……其他情況在實踐中會發生。 被檢查的異常變得不受檢查，到處都是空的catch塊，控制流與錯誤流混合在一起，有很多噪音，關鍵數據丟失了。 一團糟。

這是我們構建Takipi的主要動機， Takipi是一個Java代理，用于監視生產中的JVM，并負責使用您需要了解異常行為（以及如何避免異常）的所有信息來填補空白。

翻譯自: https://www.javacodegeeks.com/2016/06/ignore-checked-exceptions-cool-devs-based-600000-java-projects.html

忽略異常

總結

以上是生活随笔為你收集整理的忽略异常_忽略已检查的异常，所有出色的开发人员都在这样做–基于600,000个Java项目...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。