Java异常有多慢？

实际上，真正要讨论的问题并不是，“相对‘那些不会发生错误的代码’来说，‘那些以异常形式上报的错误’会有多慢？”，因为你可能也认同“已接受的回答”。相反，真正的问题是，“相对‘那些以其他形式上报的错误’来说，‘那些以异常形式上报的错误’会有多慢？”

通常认为，“不要抛出你想要捕获的异常”。所以，抛出一个其他人——如平台或框架API——要捕获的异常是合适的。或者在编写一些工具API时，抛出异常也可以的，如日志记录或消息发送，这些操作需要处理外部虚拟机的错误，例如文件IO或网络IO错误。

这是适合抛出异常的例子，应该没有人会在这些例子上有争议。现在，看一下简单方法中出现错误时会发生什么。假设方法签名如下：

调用该方法的代码如下所示：

但现在，当方法返回null时，我们想知道哪里出现错误了。简单来说可以这样：

为了实现这个功能，你需要将“return null”改为“return new TransformationException(“reason”);”。调用方法需要做改动么？

没有人会去读上面的代码块，没什么意义。所以也没什么可惊讶的。你可能每天都在写类似的代码，但也说不上是“代码异味”。可是，假设有一天你开始读到在“已预料到”的错误上使用异常是非常不好的。现在，捕获“未预料到”异常是非常可笑的，因为编写catch代码块，并显式的处理异常本身就是预料到会有异常。但没关系，我们还可以修改代码改变这种窘境。于是，我们退回到了C语言时代，返回一个异常值来表示错误。

于是，调用部分的代码也不得不奇葩一些：

所以，如果你觉着使用异常有代码异味，但可以接受打破类型安全，那么你最终要面对的是难以维护，没法使用，仅仅比基于异常的解决方案快两倍的代码。但是你又不能接受类型安全被破坏，因为这2倍的性能提升还未被证明，现在就用实在太鲁莽。所以，你决定使用结果对象，而不是返回异常值。

现在，相应地，调用部分的代码变成了这样：

现在，我们有了一个隐晦，但可管理的解决方案。可是，它比使用异常的第一个方案慢2倍，即使你将TransformResult和TransformFailure合并也是一样的。再说明一遍，使用结果对象比使用异常慢，即使在调用过程中发生了错误。每次你都需要创建一个新的结果对象，这没什么实际意义，而异常对象只在发生错误的时候才会创建。

对于异常，还有一个要讨论的地方。假设有人在使用方法transform时，没有认真看javadoc。在使用异常的例子中，会有下面的代码：

在使用异常的例子中，他们知道返回值的类型，以及是否一个“已检查异常”，他们可能会得到一个编译时错误，或者他们会在throws语句中声明相应的异常。即使是“未检查异常”，错误会传递到上层调用。现在，考虑使用异常返回值的例子：

这个粗心的用户写的代码看起来挺漂亮，但当运行过程中发生错误时，就满不是那么回事了。那时，你费尽力气提供的错误信息会因为发生了ClassCastException异常为全部丢失。使用结果对象也不会好到哪去。

再说一遍，上面的代码看来相当正常。如果他们盲目使用本文中给出的第一个方法，那么在程序运行过程中，肯定会出现NullPointerException异常。

这里主要想说的是，处理逻辑错误时，使用异常的例子可以按预想的方式正常工作，报告错误信息。但是其他的解决方案却会产生一些没用的异常，即使你已经正确将软件重新部署了一遍，它仍然会出错，只有这时，你才能得到错误信息。

所以，唯一符合逻辑性的结论是，如果你想上报错误信息，那么就应该使用异常。它比结果对象性能高，比异常返回值安全，而且运行稳定。