生产Java应用程序中的十大异常类型-基于1B事件

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方法的输入传递以下正则表达式：

1. 对于整数值：“-？\\ d +”
2. 对于浮点值：“-？\\ d +。\\ d +”

3. IllegalArgumentException – 50％的生产环境

紧随其后的是IllegalArgumentException，排在第3位，在本次调查的50％生产环境中排名前10位。

IllegalArgumentException实际上使您免于麻烦，并在将参数从意外类型传递给方法时抛出该异常。 例如，某些方法期望使用类型X，而您使用类型Y作为参数来调用它。 同样，这是由于未检查您作为其他方法的输入发送的错误而导致的错误。

IllegalArgumentException塔基皮怪兽

4. RuntimeException – 23％的生产环境

前十个列表中的所有异常对象（除Exception外）均未选中，并扩展了RuntimeException。 但是，在＃4处，我们面临着“纯” RuntimeException，在Java中，该语言实际上并未抛出任何异常。 那么这是怎么回事？

有两种主要用例可从您的代码中显式引发RuntimeException：

1. 引发新的“通用”未经检查的异常
2. 重新抛出：
   • 围绕扩展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之类的另一种情况，它必须是……您或第三方代码显式地抛出它，原因是：

1. 您需要一个异常，并且懒得指定它的实际含义。
2. 或者…更具体地说，由于某种原因，您需要抛出一个检查异常

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