该用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 里。
立即学习“Java免费学习笔记（深入）”；
- 重抛前必须把关键上下文拼进 message：
throw new BusinessException("Order " + orderId + " create failed", e) - 不要依赖日志输出来“补全”异常信息；异常本身得自包含，尤其在分布式链路追踪场景下，日志可能分散在不同服务中
- 如果用了 SLF4J，避免
log.error("msg", e)后又throw e—— 这等于把同一异常打两遍日志（捕获处 + 上层未捕获处），造成告警噪音
new 就完事，关键是让 cause 链不断、上下文不丢、类型意图清晰。很多线上问题查到最后，都是因为某次重抛时少拼了一个 ID，或者用了 initCause() 却没检查是否已被调用。 
