不该用 return -1 或 null 表示失败，因错误码混淆控制流、易被忽略且缺乏上下文；应按场景选受检异常或 RuntimeException，并设计含上下文、异常链的自定义异常。
为什么不该用 return -1 或 return null 表示失败
错误码本质是把控制流逻辑塞进返回值，调用方必须显式检查每个返回值，漏一个就埋下 NullPointerException 或业务逻辑错乱的隐患。比如 getUserById(int id) 返回 null，下游直接调用 user.getName() 就崩；而抛出 UserNotFoundException 能强制调用方处理或声明，编译器会盯住你。
常见错误现象：
- 多层嵌套调用后，错误码被无意忽略，最终表现为“功能没反应”而非明确报错
- 不同方法用相同错误码（如都用
-1），无法区分是参数错、网络超时还是数据库连接失败 - 日志里只看到
result = -1，没有堆栈、上下文、时间戳，排查成本翻倍
RuntimeException 和受检异常怎么选
Java 异常分两类：受检异常（Exception 及其子类，但不包括 RuntimeException）必须被捕获或声明；非受检异常（RuntimeException 及其子类）可自由抛出。关键不是“要不要检查”，而是“这个错误是否属于调用方能合理恢复的场景”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用受检异常表示**预期内可能失败且调用方应主动应对**的操作，比如
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，上层就只剩空壳。
