不该用 return -1 或 null 表示失败，因混淆控制流与业务逻辑、易致静默失败、无法区分错误原因、缺乏堆栈、重复校验且难追溯；应善用异常机制，按可恢复性选受检或运行时异常，自定义异常需带上下文字段并规范处理。
为什么不该用 return -1 或 return null 表示失败
错误码（比如 return 0 表示成功、return -1 表示文件未找到）把控制流和业务逻辑混在一起，调用方必须手动检查返回值，漏判就导致静默失败。Java 的异常机制强制调用链上某处必须处理或声明问题，否则编译不通过——这是编译期兜底。
-
int parseAge(String s)返回-1时，无法区分是输入为空、格式错误，还是年龄为负数的合法业务场景 - 多个嵌套调用（如
load() → decrypt() → validate()）中，每个环节都得重复写if (ret == -2) throw new XxxException()，极易遗漏 - 错误码没有堆栈信息，线上出问题时只能看到“返回 -3”，找不到哪一行抛的
RuntimeException 和受检异常（Exception）怎么选
关键看错误是否「可预期且调用方能合理恢复」：能恢复的用受检异常，不能或不该恢复的用运行时异常。
- 文件不存在（
FileNotFoundException）是典型的受检异常——调用方可以补默认配置、提示用户重选路径，所以 Java 强制你try-catch或throws - 空指针（
NullPointerException）、数组越界（ArrayIndexOutOfBoundsException）是运行时异常——属于编程缺陷，修复代码比写一堆if (obj != null)更治本 - 自定义业务异常建议继承
RuntimeException（如InsufficientBalanceException），避免污染接口签名；除非你明确要求所有调用方都做降级处理（比如支付系统强制要求处理余额不足）
自定义异常别只写个空类
一个没字段、没构造函数的 class OrderException extends RuntimeException 几乎没用——日志里只有 “OrderException”，查不出订单号、用户ID、当时金额。
public class OrderException extends RuntimeException {
private final String orderId;
private final long userId;
public OrderException(String orderId, long userId, String message) {
super(message + " [order=" + orderId + ", user=" + userId + "]");
this.orderId = orderId;
this.userId = userId;
}
// 提供 getter，方便监控系统提取结构化字段
public String getOrderId() { return orderId; }
public long getUserId() { return userId; }
}
- 构造函数里拼接上下文，确保
e.getMessage()直接可读 - 加
final字段 + getter，让 APM 工具（如 SkyWalking）能自动采集关键 ID - 避免在异常消息里拼接敏感数据（如密码、身份证号），日志可能落盘
别在 catch 里吞掉异常或只打日志
常见反模式：catch (IOException e) { logger.error("xxx", e); } —— 异常消失了，上游以为操作成功，但文件其实没写进去。
立即学习“Java免费学习笔记（深入）”；
- 真正要忽略的异常极少（比如
shutdownNow()时中断线程），必须加注释说明为什么安全 - 记录日志后，通常该重新抛出（
throw new ServiceException("上传失败", e)）或转换为更上层语义的异常 - 不要用
e.printStackTrace()，它输出到System.err，无法被日志框架捕获和分级
BusinessException 扛所有错误，等于退化回错误码时代。订单超时、库存不足、风控拒绝，这三者对前端的提示文案、重试策略、告警级别全不同——异常类型本身就是契约的一部分。 
