17370845950

该用throw重抛异常，而非throws；throw是执行语句，用于原样或封装后向上抛出异常对象，throws仅用于方法声明中表明可能抛出的异常类型，不能出现在代码块内。

什么时候该用 throw 而不是 throws 重抛异常

直接用 throw 重抛，是把当前捕获的异常对象原样往上丢；throws 是声明方法可能抛出异常，不触发实际抛出动作。很多人在 catch 块里写 throws e，结果编译报错——因为 throws 不是语句，不能出现在执行路径中。

• 重抛必须用 throw e，且 e 类型需与方法签名兼容（比如方法声明了 throws IOException，就不能 throw new RuntimeException() 直接往上抛，除非捕获的是 RuntimeException 或其子类）
• 若想转换异常类型（如把 SQLException 包装成业务异常），必须用 throw new BusinessException("DB failed", e)，此时原异常传入构造函数作为 cause
• 不要在 catch 里只写 throw e 后还加日志——这会丢失原始栈帧；应改用 throw new RuntimeException(e) 或保留 cause 的自定义异常

Exception 和 RuntimeException 封装时的关键区别

封装异常时选哪一类，本质是决定调用方是否「必须处理」。用 Exception 子类封装，强制上层加 try-catch 或 throws；用 RuntimeException 子类，则完全由开发者自觉处理，编译器不管。

• 底层 IO、网络、DB 异常建议封装为受检异常（Exception 子类），因为它们大概率需要重试或降级，不应被静默忽略
• 参数校验失败、状态不一致等逻辑错误，适合封装为 RuntimeException 子类（如 IllegalArgumentException），避免污染业务代码的异常处理流程
• 所有自定义异常若继承 RuntimeException，务必确保构造函数显式调用 super(message, cause)，否则嵌套异常信息会丢失

用 initCause() 还是构造函数传 cause？

答案是：优先用构造函数传 cause。因为 initCause() 只能调用一次，且部分 JDK 版本（如早期 6u21）在已设置 cause 后再调用会抛 IllegalStateException；而现代异常类（JDK 7+）基本都提供了带 Throwable 参数的构造函数。

public class OrderException extends Exception {
    public OrderException(String message, Throwable cause) {
        super(message, cause); // ✅ 正确：cause 在构造时绑定
    }
}

• 不要写 new OrderException("order invalid").initCause(e) —— 隐式调用链断裂风险高，且不可重复赋值
• 如果封装时不确定原始异常是否为空（比如 e 可能为 null），构造函数能自动处理；而 initCause(null) 会抛 NullPointerException
• 某些框架（如 Spring）依赖异常的 getCause() 链做分类处理，构造函数方式更稳定

日志 + 重抛时最容易丢掉的信息

最常犯的错：在 catch 里先 log.error("failed", e)，再 throw new BusinessException(e)，以为日志和异常都完整了。其实日志里打的是原始异常，而新异常的栈顶是当前 throw 行，中间断了一截——原始异常的业务上下文（比如哪个订单 ID、哪个用户）根本没进新异常的 message 里。

• 重抛前必须把关键上下文拼进 message：throw new BusinessException("Order " + orderId + " create failed", e)
• 不要依赖日志输出来“补全”异常信息；异常本身得自包含，尤其在分布式链路追踪场景下，日志可能分散在不同服务中
• 如果用了 SLF4J，避免 log.error("msg", e) 后又 throw e —— 这等于把同一异常打两遍日志（捕获处 + 上层未捕获处），造成告警噪音

封装异常不是加个 new 就完事，关键是让 cause 链不断、上下文不丢、类型意图清晰。很多线上问题查到最后，都是因为某次重抛时少拼了一个 ID，或者用了 initCause() 却没检查是否已被调用。