在Java中如何用异常替代错误码_Java异常设计优势解析_技术教程

不该用 return -1 或 null 表示失败，因错误码混淆控制流、易被忽略且缺乏上下文；应按场景选受检异常或 RuntimeException，并设计含上下文、异常链的自定义异常。

为什么不该用 `return -1` 或 `return null` 表示失败

错误码本质是把控制流逻辑塞进返回值，调用方必须显式检查每个返回值，漏一个就埋下 NullPointerException 或业务逻辑错乱的隐患。比如 getUserById(int id) 返回 null，下游直接调用 user.getName() 就崩；而抛出 UserNotFoundException 能强制调用方处理或声明，编译器会盯住你。

常见错误现象：

多层嵌套调用后，错误码被无意忽略，最终表现为“功能没反应”而非明确报错
不同方法用相同错误码（如都用 -1），无法区分是参数错、网络超时还是数据库连接失败
日志里只看到 result = -1，没有堆栈、上下文、时间戳，排查成本翻倍

`RuntimeException` 和受检异常怎么选

Java 异常分两类：受检异常（Exception 及其子类，但不包括 RuntimeException）必须被捕获或声明；非受检异常（RuntimeException 及其子类）可自由抛出。关键不是“要不要检查”，而是“这个错误是否属于调用方能合理恢复的场景”。

实操建议：

用受检异常表示**预期内可能失败且调用方应主动应对**的操作，比如 IOException（文件可能不存在）、SQLException（数据库连接可能中断）
用自定义 RuntimeException 表示**程序逻辑错误或不可恢复状态**，比如 IllegalArgumentException（ID 传了负数）、IllegalStateException（对象未初始化就调用方法）
避免滥用 throws Exception —— 它掩盖了真实失败原因，让调用方无法针对性处理

怎么设计一个真正有用的自定义异常

光写 class UserNotFoundException extends RuntimeException 不够。它得携带足够信息，让日志能定位问题，让前端能展示友好提示，让监控系统能分类告警。

关键要素：

构造函数接收 userId、traceId 等上下文，并存为字段，不要只拼在消息里（否则无法结构化提取）
重写 toString() 或提供 toLogString() 方法，确保日志输出含关键字段
如果涉及外部服务，建议包含响应状态码（如 HTTP 404）和原始错误体片段（脱敏后）

public class UserNotFoundException extends RuntimeException {
    private final long userId;
    private final String traceId;

    public UserNotFoundException(long userId, String traceId) {
        super("User not found: " + userId);
        this.userId = userId;
        this.traceId = traceId;
    }

    public long getUserId() { return userId; }
    public String getTraceId() { return traceId; }
}