在Java里什么时候不该用异常_Java异常使用边界说明_技术教程

Java中不该用异常代替控制流或状态返回：参数校验、业务规则失败、高频路径等场景滥用异常会导致性能下降、可读性差、调试困难及协作成本上升，应优先使用if判断、Optional或统一响应封装。

Java里不该用异常的地方，比该用的地方更值得警惕——异常不是控制流，也不是状态返回方式，滥用它会让代码变慢、难读、难调试。

用 `if` 能判断的，就别抛 `RuntimeException`

比如参数校验、空值检查、范围判断，这些本该是前置防御逻辑，不是“异常情况”。用异常代替 if 不仅掩盖了设计意图，还会拖慢性能（创建异常对象要收集完整堆栈）。

❌ 错误示范：把空值当异常处理

public void processUser(User user) {
    if (user == null) {
        throw new IllegalArgumentException("user cannot be null");
    }
    // ...业务逻辑
}

✅ 正确做法：提前拒绝 + 明确语义

public void processUser(User user) {
    Objects.requireNonNull(user, "user must not be null");
    // ...业务逻辑
}

性能影响：IllegalArgumentException 构造开销约是普通 if 判断的 10–50 倍（取决于堆栈深度）
可读性陷阱：调用方看到 throws IllegalArgumentException，会误以为这是“偶发错误”，而其实是“你传错了”

业务规则不满足时，慎用检查型异常（`Checked Exception`）

像“余额不足”“订单已取消”“用户未实名”这类业务规则失败，本质是正常流程分支，不是系统失常。强制要求上层 try-catch 或 throws，只会让 API 变得笨重、调用链污染严重。

❌ 常见反模式：为每个业务拒绝定义一个 InsufficientBalanceException extends Exception
✅ 更合理方案：用自定义非检查异常 + 统一响应封装（如 Spring 的 @ControllerAdvice）
兼容性风险：如果未来要把这个接口暴露为 RPC 或 HTTP API，检查型异常无法跨语言传递，反而要额外做映射层

循环体或高频路径中，绝对避免抛异常

在 for 循环、Stream 处理、IO 缓冲区解析等每秒执行成千上万次的代码路径里，抛异常等于主动引入性能瓶颈。JVM 对异常路径的 JIT 优化极弱，且每次都会触发堆栈填充。

立即学习“Java免费学习笔记（深入）”；

❌ 危险示例：用 Integer.parseInt() 解析大量字符串，靠捕获 NumberFormatException 来判断是否为数字
✅ 替代方案：用正则预检，或 Apache Commons 的 NumberUtils.isCreatable()，或 Java 17+ 的 Integer.tryParseInt()（返回 Optional）
真实影响：在吞吐量 10k QPS 的服务中，单次 NumberFormatException 抛出可能增加 0.2–0.5ms 延迟，积少成多直接拖垮 RT99

最常被忽略的一点：异常的语义边界一旦模糊，团队协作成本就指数上升。比如同一个 BusinessException 既代表“库存扣减失败”，又代表“短信网关超时”，下游根本没法区分是重试、降级还是告警。真正健壮的异常设计，不是“有没有异常”，而是“每个异常是否只说一件事”。