抛出异常,是不是错误处理的第一选择

Java 语言支持三种异常的状况:非正常异常(Error),运行时异常(Runtime Exception)和检查型异常(Checked Exception)。

异常状况的处理会让代码的效率变低,所以我们不应该使用异常机制来处理正常的状况。一个流畅的业务,理想的情况是,在执行代码时没有任何异常发生。否则,业务执行的效率就会大打折扣。

改进方案:共用错误码

js 复制代码
public sealed interface Returned<T> {
    record ReturnValue<T>(T returnValue) implements Returned {
    }
    
    record ErrorCode(Integer errorCode) implements Returned {
    }
}    

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

一个方法,返回的要么是返回值,要么是错误码,而不是同时返回两个值。

js 复制代码
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);
    };
}

返回 ReturnValue 这个许可类,就表示没有错误;返回 ErrorCode 这个许可类,就表示出现错误。这样的设计,就变得简单、皮实多了。

种方式仍然具有一些缺陷,例如它本身没有携带调试信息。在 Java 的错误处理方面,我们希望未来能够有更好的设计和更多的探索,让我们的代码更完善。


此文章为9月Day10学习笔记,内容来源于极客时间《深入剖析 Java 新特性》

相关推荐
凤山老林6 小时前
Spring Boot 启动冲刺:耗时剖析、懒加载策略与事件驱动初始化优化
spring boot·后端·python
朱涛的自习室7 小时前
我给 Gemini 4 和 DeepSeek 搞了套「末位淘汰」,AI 干活会更猛吗?(Day 3)
android·前端·后端
woniu_maggie10 小时前
SAP MDG主数据治理实战:从架构原理到项目实施全解析
后端
xiaoqiMikko10 小时前
Redis 实战(一):内存满了 —— 拒写、淘汰、被系统杀掉,以及删了 key 内存为什么不降(6.2.4 实测)
redis·后端
工程师小爱10 小时前
电芯尺寸合格,不等于电池包尺寸合格
后端
geovindu10 小时前
rust:Memento Pattern(续)
开发语言·后端·设计模式·rust·行为模式·备忘录模
闲云lazycloud10 小时前
第 1 课:Harness 与 Agent 运行时
人工智能·后端
熊哈哈O_o11 小时前
260+异构同步链路:DDL语法自动翻译在大规模数据同步中的实现原理
后端
用户98883218717411 小时前
别把 IOptionsSnapshot 注入单例:从生命周期看 .NET 配置读取
后端