大例外背后的真相

异常可能是最被滥用的Java语言功能。 这就是为什么

让我们打破一些神话。没有牙仙子。圣诞老人不是真实的。 TODO评论。 finalfinalversion-final.pdf。无皂肥皂。而且…例外实际上是例外。后者可能需要更多说服力，但我们可以帮助您。

在这篇文章中，我们邀请经验丰富的系统架构师和博客的长期朋友（最重要的是，毛茸茸的帽子的忠实拥护者）Avishai Ish-Shalom加入我们，以快速讨论Java应用程序中异常的当前状态。。这是我们发现的。

根据定义，异常与正常情况相去甚远

让我们从Java官方文档的引用开始：“异常是在程序执行期间发生的事件，破坏了正常的指令流程”。诚实的披露：我们自己添加了上限。

实际上，在大多数应用程序中，正常的指令流充满了这些所谓的“正常”异常的“正常”重复，这些异常会导致“正常”中断。

exception-meme-300x259 @ 2x

在大多数应用程序中，噪声水平越来越高，抛出，记录，然后索引和分析的异常……大多数没有意义。

除了对系统造成不必要的压力外，这种操作噪音还会使您失去与真正重要的异常的联系。想象一下一个电子商务应用程序发生了一个新的重要异常，该异常开始发生，表示出了点问题并受到影响，例如100个用户无法检出。现在，用数千个无用的“正常”异常掩盖它，并尝试了解出了什么问题。

例如，大多数应用程序具有“正常”级别的错误事件。在下面的屏幕截图中，我们可以看到每小时大约有4k个事件：

例外情况

Takipi的错误分析仪表板–错误趋势

如果我们“幸运”，那么一个新的错误会在图中显示为峰值，就像我们在这里一样，在凌晨1点（糟糕）发生IllegalStateException数十万次。我们可以立即看到导致峰值的原因。

绿线表示事件总数，其余各行表示特定的异常和记录的错误/警告。

危险来自异常，只有很少，很小但致命的实例被掩埋在所谓的“正常”异常级别内。

您所说的这些“正常”例外是什么？

与需要更改代码才能解决的实际错误不同，当今的异常表明了很多其他情况，这些情况实际上并没有任何可行的见解。他们只会减轻系统负担。考虑任何有经验的开发人员可以预期的以下两种情况：

业务错误 –用户/数据可能会执行业务流程所不允许的任何事情。像任何形式的表单验证一样，在电话号码表单字段中填写文本，用空购物车签出，等等。在内部，NumberFormatException 在我们的最新文章中也排名前10名，排名前 2位在生产环境中为1B 。
系统错误 –您从操作系统中询问的所有内容都可能说不，这是您无法控制的。例如，尝试访问您没有权限的文件。

另一方面，真正的异常是您在编写代码时没有意识到的事情，例如OutOfMemoryException甚至是NullPointerException，它们使事情异常混乱。需要您采取措施解决问题的问题。

Inconceviable-Exceptions-300x278 @ 2x

异常旨在崩溃和燃烧

未捕获的异常会杀死您的线程，甚至在重要线程死机而其余线程都在等待时，甚至可能使整个应用程序崩溃或使其处于某种“僵尸状态”。有些应用程序知道如何处理，大多数却不知道。

Java中的异常的主要目的是帮助您捕获错误并解决它，而不是跨入应用程序逻辑领域。它们旨在帮助调试，这就是为什么他们尝试从应用程序的角度包含尽可能多的信息。

这可能造成的另一个问题是状态不一致，当应用程序流变得……跳动时，甚至比goto语句还要糟糕。它具有相同的缺点，但也有一些曲折：

它破坏了程序的流程
很难跟踪和理解下一步会发生什么
即使有finally块也很难清理
重量级，与“ goto”不同，它随身携带所有堆栈和其他额外数据

无例外地使用“错误”流程

如果您尝试使用异常处理应由应用程序逻辑处理的可预测情况，那么您会遇到麻烦。大多数Java应用程序都遇到同样的麻烦。

本书预计不会发生的问题并不是真正的例外。一个有趣的解决方案来自Scala的Futures –毫无例外地处理错误。来自官方scala文档的Scala示例：

import scala.util.{Success, Failure}val f: Future[List[String]] = Future {session.getRecentPosts
}f onComplete {case Success(posts) => for (post <- posts) println(post)case Failure(t) => println("An error has occured: " + t.getMessage)
}

将来在内部运行的代码可能会引发异常，但这些异常将被包含在内并且不会泄漏到外部。 Failure（t）分支明确表明了失败的可能性，并且很容易遵循代码执行。

在新的Java 8 CompletableFuture功能（我们最近才写过）中，我们可以使用completeExceptionally（），尽管它不那么漂亮。

使用API时情节变得更浓

假设我们有一个使用库进行数据库访问的系统，那么数据库库如何将其错误暴露给外界？欢迎来到狂野的西部。并且请记住，库可能仍然会引发一般错误，例如java.net.UnknownHostException或NullPointerException

一个现实的例子是如何解决这个问题的是包装JDBC的库，它只是抛出一个通用的DBException而没有给您机会让您知道出了什么问题。也许一切都很好，并且只有连接错误，或者……您实际上需要更改一些代码。

常见的解决方案是使用基本异常（例如DBException）的数据库库，该库异常将从中继承。这使库用户可以使用一个try块捕获所有库错误。但是，可能导致库错误的系统错误呢？常见的解决方案是将发生的任何异常包装起来。因此，如果它无法解析DNS地址（更多是系统错误，然后是库错误），它将捕获该地址并抛出此更高级别的异常-库用户应该知道该异常。尝试捕获恶梦，带有嵌套异常的提示包装了其他异常。

如果我们将Actors混合在一起，则控制流程甚至变得更加混乱。带有异常的异步编程是一团糟。它可以杀死一个Actor ，然后重新启动它，一条消息将以原始错误发送给其他Actor ，您将丢失堆栈。