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<T>(T returned, int errorCode) {
    // blank
};

如果一个方法执行成功,它的返回值应该存放在Coded的returned变量里;如果执行失败,失败的错误码应该存放在Coded的errorCode变量里。我们可以把讨论案例里的of方法,修改成使用错误码的形式,就像下面的这段代码这样。

public static Coded<Digest> of(String algorithm) {
    return switch (algorithm) {
        case "SHA-256" -> new Coded(sha256, 0);
        case "SHA-512" -> new Coded(sha512, 0);
        default -> new Coded(null, -1);
    };
}

对应地,这个方法的使用就需要处理错误码。下面的代码,就是一个该怎么使用错误码的例子。

Coded<Digest> coded = Digest.of("SHA-256");
if (coded.errorCode() != 0) {
    // snipped
} else {
    coded.returned().digest("Hello, world!".getBytes());
}

看了上面的代码,我想你应该已经能够判断出来它的性能状况了。我们还是用基准测试来验证一下我们猜想吧。

测试结果显示,没有返回错误码的用例,它能够支持的吞吐量和返回错误码的用例几乎没有差别。这就是我们想要的结果。

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<Digest> of(String algorithm) {
    return switch (algorithm) {
        // INCORRECT: set both error code and value.
        case "SHA-256" -> new Coded(sha256, -1);
        case "SHA-512" -> new Coded(sha512, 0);
        default -> new Coded(sha256, -1);
    };
}

我们再来看看使用错误码的代码。使用错误码,也有一条铁的纪律:必须首先检查错误码,然后才能使用返回值。同样,编译器也不会帮助我们检查违反纪律的错误。下面的代码,就没有正确使用错误码。我们需要依靠经验才能避免这样的错误。所以,使用错误码的方式,也不够皮实。

Coded<Digest> coded = Digest.of("SHA-256");
// INCORRECT: use returned value before checking error code.
coded.returned().digest("Hello, world!".getBytes());

需要的纪律越多,我们犯错的可能性就越大。那有没有改进的方案,能够减少这些额外的要求呢?

改进方案:共用错误码

我们希望,改进的方案能够同时考虑生成错误码和使用错误码两端的需求。下面这段代码就是一个改进的设计。

public sealed interface Returned<T> {
    record ReturnValue<T>(T returnValue) implements Returned {
    }
    
    record ErrorCode(Integer errorCode) implements Returned {
    }
}    

在这个改进的设计里,我们使用了封闭类。我们知道封闭类的子类是可以穷举的,这是这项改进需要的一个重要特点。我们把Returned的许可类(ReturnValue和ErrorCode)定义成档案类,分别表示返回值和错误代码。这样,我们就有了一个精简的方案。

下面这段代码,就是用新方案生成返回值和错误码的一个例子。可以看到,相比较使用Coded档案类的例子,这里的返回值和错误码分离开了。一个方法,返回的要么是返回值,要么是错误码,而不是同时返回两个值。这种方式,又把我们带回到了熟悉的编码方式。

public static Returned<Digest> of(String algorithm) {
    return switch (algorithm) {
        case "SHA-256" -> new ReturnValue(new SHA256());
        case "SHA-512" -> new ReturnValue(new SHA512());
        case null, default -> new ErrorCode(-1);
    };
}

而且,生成Coded实例需要遵守的两条纪律,在这里也不需要了。因为,返回ReturnValue这个许可类,就表示没有错误;返回ErrorCode这个许可类,就表示出现错误。这样的设计,就变得简单、皮实多了。

接下来,我们再看看使用错误码的情况。下面的这段代码,我们使用了前面讨论过的switch匹配的新特性。Returned这个封闭类被设计成了一个没有方法的接口,要想获得返回值,我们就必须要使用它的许可类ReturnValue,或者ErrorCode。

Returned<Digest> rt = Digest.of("SHA-256");
switch (rt) {
    case ReturnValue rv -> {
            Digest d = (Digest) rv.returnValue();
            d.digest("Hello, world!".getBytes());
        }
    case ErrorCode ec ->
            System.out.println("Failed to get instance of SHA-256");
}

如果一个方法的调用返回的是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<Digest> rt = Digest.of("SHA-256");
        switch (rt) {
            case Returned.ReturnValue rv -> {
                    Digest d = (Digest) rv.returnValue();
                    d.digest("Hello, world!".getBytes());
                }
            case Returned.ErrorCode ec ->
                    System.out.println("Failed to get instance of SHA-256");
        }
    }
}

欢迎你在留言区留言、讨论,分享你的阅读体验以及验证的代码和结果。我们下节课再见!

注:本文使用的完整的代码可以从GitHub下载,你可以通过修改GitHubreview template代码,完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见,请提交一个 GitHub的拉取请求(Pull Request),并把拉取请求的地址贴到留言里。这一小节的拉取请求代码,请在错误处理专用的代码评审目录下,建一个以你的名字命名的子目录,代码放到你专有的子目录里。比如,我的代码,就放在error/review/xuelei的目录下面。