08 抛出异常，是不是错误处理的第一选择？ 你好，我是范学雷。从今天开始，我们进入这个专栏的第二个部分。在这一部分，我们重点聊一聊代码的性能。这节课呢，我想跟你讨论Java的错误处理。
Java的错误处理，算不上是特性。但是Java错误处理的缺陷和滥用，却一直是一个很有热度的话题。 其中，Java异常的使用和处理，是滥用最严重，诟病最多，也是最难平衡的一个难题。
为了解决花样百出的Java错误处理问题，也有过各种各样的办法。然而，到目前为止，我们还没有看到能解决所有问题的好方法，这也是编程语言研究者们的努力方向。
不过也正是因此，我们就更需要掌握Java错误处理的机制，平衡使用各种解决办法，妥善处理好Java异常。我们还是通过案例和代码，来看看Java异常的滥用，以及可能的解决方案吧。
阅读案例
我们知道，Java语言支持三种异常的状况：非正常异常（Error），运行时异常（Runtime Exception）和检查型异常（Checked Exception）。关于这三种异常状况的介绍，你可以参考《异常处理都有哪些陷阱？》这篇文章。
通常情况下，我们谈到异常的时候，除非有特别的声明，不然指的都是运行时异常或者检查型异常。
我们还知道，异常状况的处理会让代码的效率变低，所以我们不应该使用异常机制来处理正常的状况。一个流畅的业务，理想的情况是，在执行代码时没有任何异常发生。否则，业务执行的效率就会大打折扣。
异常处理对代码执行效率的影响有多大呢？我们先要对这个问题有一个直观的感受，然后才能体会“不应该使用异常机制来处理正常的状况”这句话的分量，认识到异常滥用的危害。
下面的这段代码，测试了两个简单用例的吞吐量。这两种状况，都试图截取一段字符串。但是其中一个基准测试没有抛出异常；另外一个基准测试，由于字符串访问越界，抛出了运行时异常。为了让两个基准测试更具有对比性，我们在两个基准测试里，使用了相同的代码结构。 package co.ivi.jus.agility.former; // snipped public class OutOfBoundsBench { private static String s = “Hello, world!”; // s.length() == 13. // snipped @Benchmark public void withException() { try { s.substring(14); } catch (RuntimeException re) { // blank line, ignore the exception. } } @Benchmark public void noException() { try { s.substring(13); } catch (RuntimeException re) { // blank line, ignore the exception. } } }
基准测试的结果可能会让你大吃一惊。没有抛出异常的用例，它能够支持的吞吐量要比抛出异常的用例大1000倍。
Benchmark Mode Cnt Score Error Units OutOfBoundsBench.noException thrpt 15 566348609.338 ± 22165278.114 ops/s OutOfBoundsBench.withException thrpt 15 504193.920 ± 26489.992 ops/s
如果用运营成本来衡量一下的话，你可以考虑按照使用的计算资源来计算费用的环境，比如云计算。如果没有抛出异常的用例要花一万块钱的话，抛出异常的用例就需要1000万才能支持相同数量的用户。如果一个黑客能够找到这样的运行效率问题，它足以让一个应用多掏1000倍的钱，或者直到应用耗尽分配的计算资源，无法继续提供服务为止。
这样的评估当然很粗陋，但是足以说明抛出异常对软件效率的影响。我们当然不希望我们编写的代码存在这么一个烧钱的问题。
这时候我们就会设想：我们的代码，能不能没有任何异常状况发生？我们前面也提到过，“一个流畅的业务，理想的情况是，在执行代码时没有任何异常状况发生”。
可惜，这几乎是无法完成的任务。随便翻一翻Java的代码，不管是JDK这样的核心类库，还是支持业务的应用软件，我们都能看到大量的异常处理代码。
比如说吧，我们要用Java搭建一个服务器。通常情况下，如果业务逻辑出现了问题，比如说用户输入的数据不合规范，我们都会抛出一个异常，标记出问题的数据，并且记录下来问题出现的路径。但是，无论出现什么样的业务问题，服务器崩溃都是不能接受的结果。所以，我们的服务器会捕获所有的异常，不管是运行时异常，还是检查型异常；然后从异常中恢复过来，继续提供服务。
但是场景是否异常有时候只是角度问题。比如说：输入数据不规范，从检查用户数据代码这个角度去看，这是一个不正常的情景，所以抛出异常；但是，如果从要求不间断运营的服务器的角度来看，这就只是一个需要应用程序妥善处理的正常状况，是一个正常的情景了。所以，服务器要能够从这样的异常中恢复过来，继续运行。
然而，现在稍微复杂一点的软件，都是很多类库集成的。大部分类库，都只从自己的角度考虑问题，并且使用异常来处理遇到的问题。除非是很简单的代码，不然我们很难期望一个业务执行下来没有任何异常状况发生。
毫无疑问，抛出异常影响了代码的运行效率。但是，我们又没有别的办法躲开这样的影响。所以，有些新的编程语言（比如Go语言）干脆就彻底抛弃了类似于Java这样的异常机制，重新拥抱C语言的错误码方式。
讨论案例
接下来的讨论，为了方便我们反复地修改代码，我会使用下面这个案例。
我们知道，在设计算法公开接口的时候，算法的敏捷性是必须要考虑的问题。因为，算法总是会演进，旧的算法会过时，新的算法会出现。一个应用程序，应该能够很方便地升级它的算法，自动地淘汰旧算法，采纳新算法，而不需要太大的改动，甚至不需要改动源代码。所以，算法的公开接口经常使用通用的参数和结构。
比如说，我们获取一个单项散列函数实例的时候，一般不会直接调用这个单项散列函数的构造函数。而是用一个类似于工厂模式的集成环境，来构造出这个单项散列函数的实例。
就像下面的这段代码里的of方法。这个of方法，使用了一个字符串作为输入参数。我们可以把它作为配置参数写在配置文件里。修改配置文件之后，不需要改动调用它的源代码就能升级算法了。 package co.ivi.jus.agility.former; import java.security.NoSuchAlgorithmException; public sealed abstract class Digest { private static final class SHA256 extends Digest { @Override byte[] digest(byte[] message) { // snipped } } private static final class SHA512 extends Digest { @Override byte[] digest(byte[] message) { // snipped } } public static Digest of(String algorithm) throws NoSuchAlgorithmException { return switch (algorithm) { case “SHA-256” -> new SHA256(); case “SHA-512” -> new SHA512(); default -> throw new NoSuchAlgorithmException(); }; } abstract byte[] digest(byte[] message); }
当然，通用参数也有它自己的问题。比方说，字符串的输入参数可能有疏漏，或者不是一个可以支持的算法。这时候，站在of方法的角度，就需要处理这样的异常状况。反映到代码上，of方法要声明如何处理不合法的输入参数。上面的代码，使用的办法是抛出一个检查型异常。
那么，使用这个of方法的代码，就需要处理这个检查型异常。下面的代码，描述的就是一个使用这个方法的典型的例子。 try { Digest md = Digest.of(digestAlgorithm); md.digest(“Hello, world!”.getBytes()); } catch (NoSuchAlgorithmException nsae) { // snipped }
既然使用了异常处理，当然也就会有我们在阅读案例里讨论过的异常处理的性能问题。我也试着给这个方法做了异常处理方面的基准测试。测试结果显示，没有抛出异常的用例，它能够支持的吞吐量要比抛出异常的用例大了将近2000倍。有了前面阅读案例的知识和铺垫，你应该对这样的性能差异早已有了心理准备。
Benchmark Mode Cnt Score Error Units ExceptionBench.noException thrpt 15 1318854854.577 ± 14522418.634 ops/s ExceptionBench.withException thrpt 15 713057.511 ± 16631.048 ops/s
重回错误码
那么，既然异常处理的效率这么让人揪心，我们编写的Java代码能够像Go语言一样重回错误码方式吗？这是我们首先要探索的一个方向。
也就是说，如果一个方法不需要返回值，我们可以试着把它修改为返回错误码。这是一个很直观的修改方式。
- // no return value - public void doSomething(); + // return an error code if run into problems, otherwise 0. + public int doSomething();
但是，如果一个方法需要一个返回值，我们就不能使用只返回错误码这种方式了。如果有一种方法，既能返回返回值，也能返回错误码，那么代码就会得到显著的改善。因此，我们需要设计一个数据结构，来支持这样的返回方式。
下面代码里的Coded这个档案类，就是一个能够满足这样要求的数据结构。
public record Coded
如果一个方法执行成功，它的返回值应该存放在Coded的returned变量里；如果执行失败，失败的错误码应该存放在Coded的errorCode变量里。我们可以把讨论案例里的of方法，修改成使用错误码的形式，就像下面的这段代码这样。
public static Coded
对应地，这个方法的使用就需要处理错误码。下面的代码，就是一个该怎么使用错误码的例子。
Coded
看了上面的代码，我想你应该已经能够判断出来它的性能状况了。我们还是用基准测试来验证一下我们猜想吧。
测试结果显示，没有返回错误码的用例，它能够支持的吞吐量和返回错误码的用例几乎没有差别。这就是我们想要的结果。 Benchmark Mode Cnt Score Error Units CodedBench.noErrorCode thrpt 15 1320977784.955 ± 7487395.023 ops/s CodedBench.withErrorCode thrpt 15 1068513642.240 ± 69527558.874 ops/s
重回错误码的缺陷
不过，重回错误码的选择并不是没有代价的。刚才，我们在性能优化的同时，也放弃了代码的可读性和可维护性。异常处理能够解决掉的，也就是C语言时代的错误处理的缺陷，又重新回来了。
需要更多的代码
使用异常处理的代码，我们可以在一个try-catch语句块里包含多个方法的调用；每一个方法的调用都可以抛出异常。这样，由于异常的分层设计，所有的异常都是Exception的子类；我们也就可以一次性地处理多个方法抛出的异常了。 try { doSomething(); // could throw Exception doSomethingElse(); // could throw RuntimeException socket.close(); // could throw IOException } catch (Exception ex) { // handle the exception in one place. }
如果使用了错误码的方式，每一个方法调用都要检查返回的错误码。一般情况下，同样的逻辑和接口结构，使用错误码的方式需要编写更多的代码。
对于简单的逻辑和语句，我们可以使用逻辑运算符合并多个语句。这种紧凑的方式，牺牲了代码的可读性，不是我们喜欢的编码风格。 if (doSomething() != 0 && doSomethingElse() != 0 && socket.close() != 0) { // handle the exception }
但是，对于复杂的逻辑和语句来说，紧凑的方式就行不通了。这时候，就需要一个独立的代码块来处理错误码。这样的话，结构重复的代码就会增加，这是我们在C语言编写的代码里经常见到的现象。
if (doSomething() != 0) { // handle the exception }; if (doSomethingElse() != 0) { // handle the exception }; if (socket.close() != 0) { // handle the exception }
丢弃了调试信息
不过，重回错误码最大的代价，是可维护性大幅度降低。使用异常的代码，我们能够通过异常的调用堆栈，清楚地看到代码的执行轨迹，快速找到出问题的代码。这也是我们使用异常处理的主要动力之一。 Exception in thread “main” java.security.NoSuchAlgorithmException: \ Unsupported digest algorithm SHA-128 at co.ivi.jus.agility.former.Digest.of(Digest.java:31) at co.ivi.jus.agility.former.NoCatchCase.main(NoCatchCase.java:12)
但是，使用错误码之后，就不再生成调用堆栈了。虽然这可以让资源的消耗减少，也能够提升代码性能，但是调用堆栈能带来的好处也就没有了。
另外，能够快速地找到代码的问题，也是一个编程语言的竞争力。如果我们决定重回错误码的处理方式，千万不要忘了提供快速排查问题的替代方案。比如使用更详尽的日志，或者使用启用JFR（Java Flight Recorder）来收集诊断和分析数据。如果没有替代方案，我相信你会非常怀念使用异常的好处。
其实呀，C语言时代的错误码，和Java语言时代的异常处理机制，就像是跷跷板的两端，一端是性能，一端是可维护性。在Java诞生的时候，有一个假设，就是计算能力会快速演进，所以性能的分量会有所下降，而可维护性的分量会放得很重。然而，如果演进到按照计算能力计费的时代，我们可能需要重新考量这两个指标各自所占的比重了。这时候，一部分代码可能就需要把性能的分量放得更重一些了。
易碎的数据结构
如果你阅读过我的另外一个专栏《代码精进之路》，你应该能够理解，一个新机制的设计，必须要简单、皮实。所谓的皮实，就是怎么用怎么对，纪律少、要求低，不容易犯错误。我们使用这样的准则，来看看上面设计的Coded这个档案类，是不是足够皮实。
生成一个Coded的实例，需要遵守两条纪律。第一条纪律是错误码的数值必须一致，0代表没有错误，如果是其他的值表示出现了错误；第二条纪律是不能同时设置返回值和错误码。违反了任何一条纪律，都会出现不可预测的错误。
但是，这两条纪律需要编写代码的人自觉实现，编译器不会帮助我们检查错误。
比如下面的代码，对于编译器来说就是合法的代码。但对我们来说，这样的代码很明显违反了使用错误码需要遵守的规矩。这也就意味着，生成错误码的方式，不够皮实。
public static Coded
我们再来看看使用错误码的代码。使用错误码，也有一条铁的纪律：必须首先检查错误码，然后才能使用返回值。同样，编译器也不会帮助我们检查违反纪律的错误。下面的代码，就没有正确使用错误码。我们需要依靠经验才能避免这样的错误。所以，使用错误码的方式，也不够皮实。
Coded
需要的纪律越多，我们犯错的可能性就越大。那有没有改进的方案，能够减少这些额外的要求呢？
改进方案：共用错误码
我们希望，改进的方案能够同时考虑生成错误码和使用错误码两端的需求。下面这段代码就是一个改进的设计。
public sealed interface Returned
在这个改进的设计里，我们使用了封闭类。我们知道封闭类的子类是可以穷举的，这是这项改进需要的一个重要特点。我们把Returned的许可类（ReturnValue和ErrorCode）定义成档案类，分别表示返回值和错误代码。这样，我们就有了一个精简的方案。
下面这段代码，就是用新方案生成返回值和错误码的一个例子。可以看到，相比较使用Coded档案类的例子，这里的返回值和错误码分离开了。一个方法，返回的要么是返回值，要么是错误码，而不是同时返回两个值。这种方式，又把我们带回到了熟悉的编码方式。
public static Returned
而且，生成Coded实例需要遵守的两条纪律，在这里也不需要了。因为，返回ReturnValue这个许可类，就表示没有错误；返回ErrorCode这个许可类，就表示出现错误。这样的设计，就变得简单、皮实多了。
接下来，我们再看看使用错误码的情况。下面的这段代码，我们使用了前面讨论过的switch匹配的新特性。Returned这个封闭类被设计成了一个没有方法的接口，要想获得返回值，我们就必须要使用它的许可类ReturnValue，或者ErrorCode。
Returned
如果一个方法的调用返回的是Returned实例，我们就知道，它要么是代表返回值的ReturnValue对象，要么是代表错误码的ErrorCode对象。而且，你要使用返回值，就必须检查它是不是一个ReturnValue的实例。这种情况下，使用Coded档案类编写代码需要遵守的纪律，也就是必须先检查错误码，在这里也不需要了。使用错误码的这一端，也变得更加简单、皮实了。
当然，使用封闭类来分别表示返回值和错误码的方式，只是改进错误码的其中一种方式。这种方式仍然具有一些缺陷，例如它本身没有携带调试信息。在Java的错误处理方面，我们希望未来能够有更好的设计和更多的探索，让我们的代码更完善。
总结
好，这节课就讲到这里，我来做个小结。从前面的讨论中，我们了解了Java异常处理带来的性能问题，我还给你展示了使用错误码的方式进行错误处理的方案。使用错误码的方式进行错误处理，错误码不能携带调试信息，这提高了错误处理的性能，但是增加了错误排查的困难，降低了代码的可维护性。
我们在代码里，是应该使用错误码，还是应该使用异常，这是一个需要根据应用场景认真权衡的问题。Java的新特性，尤其是封闭类和档案类，为我们在Java的软件里使用错误码的形式，提供了强大的支持，让我们有了新的选择。
如果你想要丰富你的代码评审清单，错误码可以作为一个可评估的选项，进入你的考察指标内： 使用异常的机制进行错误处理，是不是一个最优的选择？
另外，我还拎出了几个今天讨论过的技术要点，这些都可能在你们面试中出现哦。通过今天的学习，你应该能够：
-
清楚Java异常处理所带来的性能问题，对这一问题的影响程度有一个大致的概念；
- 面试问题：你知道Java异常处理会产生什么问题吗？
-
了解Java异常处理的替代方案，以及它的优势和劣势；
- 面试问题：你知道怎么提高Java代码的性能吗？
使用封闭类和档案类这样的Java新技术，为Java的错误处理寻求一个替代方案，这是一个崭新的、尚未开发的课题。在面试的时候，我们经常会遇到对代码性能有着苛刻要求的场景，如果你能够借助新特性展示错误处理的替代方案，并且不回避这个方案存在的问题，这一定是一个彰显你创新能力的好时机。
思考题
在前面的替代方案中，我们使用封闭类来分别表示了返回值和错误码，在使用错误码的代码里，我们使用了switch的模式匹配。可是，直到JDK 17，switch的模式匹配这个特性还只是一个预览版，还没有最终定稿。一般情况下，我们可以研究探索，但是不推荐使用预览版的特性。那么，如果不使用switch的模式匹配，使用错误码的代码可能是什么样子的呢？这是这一次的思考题。
为了方便你阅读，我把switch模式匹配的代码放在了下面。你可以在这个基础上替换掉switch模式匹配，看看最后会是什么样子的。
package co.ivi.jus.error.review.xuelei; import co.ivi.jus.error.union.Digest; import co.ivi.jus.error.union.Returned; public class UseCase { public static void main(String[] args) { Returned
欢迎你在留言区留言、讨论，分享你的阅读体验以及验证的代码和结果。我们下节课再见！
注：本文使用的完整的代码可以从GitHub下载，你可以通过修改GitHub上review template代码，完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见，请提交一个 GitHub的拉取请求（Pull Request），并把拉取请求的地址贴到留言里。这一小节的拉取请求代码，请在错误处理专用的代码评审目录下，建一个以你的名字命名的子目录，代码放到你专有的子目录里。比如，我的代码，就放在error/review/xuelei的目录下面。
参考资料
https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%b7%b1%e5%85%a5%e5%89%96%e6%9e%90Java%e6%96%b0%e7%89%b9%e6%80%a7/08%20%e6%8a%9b%e5%87%ba%e5%bc%82%e5%b8%b8%ef%bc%8c%e6%98%af%e4%b8%8d%e6%98%af%e9%94%99%e8%af%af%e5%a4%84%e7%90%86%e7%9a%84%e7%ac%ac%e4%b8%80%e9%80%89%e6%8b%a9%ef%bc%9f.md
更多学习
更多实时资讯，前沿技术，生活趣事。尽在【老马啸西风】
交流社群：[交流群信息](https://mp.weixin.qq.com/s/rkSvXxiiLGjl3S-ZOZCr0Q)
