17370845950

不该用 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; }
}

异常链（cause）不是可选功能，是必填项

底层抛出 SQLException，中间层包装成 UserLoadException，再往上抛给 Controller —— 如果没把原始异常设为 cause，你就永远丢失了 SQL 错误码、具体哪条语句失败、甚至数据库连接池耗尽的线索。

正确做法：

• 所有包装异常必须传入 cause 参数：new UserLoadException("load failed", e)
• 日志框架（如 Logback）默认打印 cause 的完整堆栈，别手动 e.getCause().getMessage() —— 那只会截断信息
• Spring MVC 中，全局异常处理器可通过 Throwable.getRootCause() 拿到最底层异常，用于精细化响应码映射

最容易被忽略的一点：很多团队写了自定义异常，却在构造函数里忘了调用 super(message, cause)，导致整个异常链断裂。只要没显式传递 cause，上层就只剩空壳。