Pareto記錄原理：97％的記錄錯誤語句是由3％的唯一錯誤引起的

在最新的數據整理帖子之后，我們收到了很多反饋和問題，在該文章中，我們顯示97％的記錄錯誤是由10個唯一錯誤引起的 。 根據普遍的需求，我們將更深入地研究此研究中包含的1,000多個應用程序中的頂級異常類型。

來吧。

（順便說一下，這是我們的第一篇推薦配樂， 請檢查一下自己 ）

無須再做：按類型劃分的頂級異常

為了提取數據，我們從Takipi的錯誤分析微代理監視的1000多個應用程序中提取了匿名統計信息，并檢查了每個公司的十大例外類型。 然后，我們將所有數據合并，得出總體前十名的列表。

每個生產環境都不同，研發團隊使用不同的第三方庫，并且擁有自己的自定義例外類型。 從更大的角度看，標準異常脫穎而出，并且一些有趣的模式變得可見。

真數據

1. NullPointerException – 70％的生產環境

是。 臭名昭著的NullPointerException位于＃1。 Null Reference的發明者Charles Antony Richard Hoare爵士說的沒錯：

“我稱之為我十億美元的錯誤。 這是在1965年發明空引用的結果。它導致了無數的錯誤，漏洞和系統崩潰，在最近40年中可能造成十億美元的痛苦和破壞。

在我們研究的70％的生產環境中，NPE排在前十位，位居第一。 在Takipi ，我們實際上有一個特殊的警報，每當在系統上引入新的NullPointerException時，我們都可以通過它來知道自己的設置 。

塔基皮NPE怪物

2. NumberFormatException – 55％的生產環境

在＃2中是NumberFormatException，它在您嘗試將字符串轉換為數字值且String格式不正確時發生。 它擴展了IllegalArgumentException，該異常也在這里＃3出現。

一種簡單的修復方法是確保傳遞給parse方法的輸入傳遞以下正則表達式：

對于整數值：“-？\\ d +”

對于浮點值：“-？\\ d +。\\ d +”

3. IllegalArgumentException – 50％的生產環境

緊隨其后的是IllegalArgumentException，排在第3位，在本次調查的50％生產環境中排名前10位。

IllegalArgumentException實際上使您免于麻煩，并在將參數從意外類型傳遞給方法時拋出該異常。 例如，某些方法期望使用類型X，而您使用類型Y作為參數來調用它。 同樣，這是由于未檢查您作為其他方法的輸入發送的錯誤而導致的錯誤。

IllegalArgumentException塔基皮怪獸

4. RuntimeException – 23％的生產環境

前十個列表中的所有異常對象（除Exception外）均未選中，并擴展了RuntimeException。 但是，在＃4處，我們面臨著“純” RuntimeException，在Java中，該語言實際上并未拋出任何異常。 那么這是怎么回事？

有兩種主要用例可從您的代碼中顯式引發RuntimeException：

引發新的“通用”未經檢查的異常

重新拋出：

• 圍繞擴展RuntimeException的另一個異常“包裝”一個常規的未經檢查的異常
• 取消檢查異常

關于已檢查與未檢查以及我們在此描述的最后一個用例的著名故事來自亞馬遜的AWS開發工具包，該工具僅拋出未檢查的異常并拒絕使用已檢查的異常。

Takipi RuntimeExceptionMonster

5. IllegalStateException – 22％的生產環境

在第5名中，IllegalStateException是本帖所涵蓋的1,000多個應用程序中的22％中排名前10位的例外。

當您嘗試在不適當的時間使用方法時，會引發IllegalStateException，例如…在《 我如何與母親見面》的第一集中與Ted和Robin的場景。

一個更現實的Java示例是，如果您使用URLConnection，嘗試做一些假設您未連接的操作，并得到“ IllegalStateException：已連接”。

6. NoSuchMethodException –生產環境的16％

這樣的方法，很混亂 。 在此數據緊縮中，有16％的生產環境在其前10名中具有NoSuchMethodException。

由于我們大多數人在喝醉的時候不會寫代碼，至少在白天沒有這么做，這并不一定意味著我們會以為自己看到的東西不那么瘋狂。 這樣一來，編譯器就可以在過程的較早階段捕獲這種方式。

當您嘗試使用不存在的方法時，會引發此異常，當您使用反射并從某個變量獲取方法名稱，或者針對某個類的版本進行構建并使用在生產中使用另一種（感謝@braxuss ）。

7. ClassCastException – 15％的生產環境

當我們試圖將一個類強制轉換為另一個非實例的類時，就會發生ClassCastException。 15％的生產環境將其排在前10位，這很麻煩。

規則是，不能將對象強制轉換為不繼承對象的其他類。 大自然曾經做過一次，當時沒人在看，這就是我們得到…… Java鼠標鹿的方式 。 是的，那是一個真實的生物。

8.例外–生產環境的15％

在＃8中，所有例外項的母親Exception， DUN DUN DUUUUN （祖母可投擲 ）。

Java從不拋出簡單的異常，因此這是RuntimeException之類的另一種情況，它必須是……您或第三方代碼顯式地拋出它，原因是：

您需要一個異常，并且懶得指定它的實際含義。

或者…更具體地說，由于某種原因，您需要拋出一個檢查異常

9. ParseException – 13％的生產環境

解析錯誤再次發出！ 每當我們傳遞字符串以將其解析為其他內容，并且未按照應有的格式對其進行格式化時，就會被ParseException擊中。 笨蛋

在這篇文章中測試的13％的生產環境中，前十名中都包含此異常，這比您想象的要普遍。

解決的方法是……再次檢查自己。

10. InvocationTargetException – 13％的生產環境

Java Reflection領域拋出的另一個異常是InvocationTargetException。 實際上，這是一個包裝，如果在調用的方法中出現問題，則將該異常包裝到InvocationTargetException中。

要獲取原始異常，您必須使用getTargetException方法。

我們看到這篇文章中測試的13％的生產環境將其列入前十大例外列表中。 這里的第二種異常類型與Java的反射功能直接相關。

最后的想法

Java異常的世界確實豐富多彩，令人驚訝的是，前十大異常對我們的日志有多大影響。 所有記錄的錯誤中有97％來自10個唯一異常。

嘗試Takipi ，找出您自己的生產環境中最常見的10個例外，開始只需幾分鐘，您還可以獲得修復它們所需的所有數據。 源，堆棧，狀態。

翻譯自: https://www.javacodegeeks.com/2016/06/top-10-exception-types-production-java-applications-based-1b-events.html

總結

以上是生活随笔為你收集整理的生产Java应用程序中的十大异常类型-基于1B事件的全部內容，希望文章能夠幫你解決所遇到的問題。

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