必须用throw重新抛出捕获的异常当且仅当当前方法无法履行职责且调用方需感知错误，典型场景包括封装底层异常、补充上下文或清理后仍需通知上层；错误做法是盲目throw e或在finally中throw导致异常掩盖。
什么时候必须用 throw 重新抛出捕获的异常
不是所有 catch 块都要再 throw，只有当当前方法无法完成职责、且调用方需要感知错误时才该这么做。典型场景包括：封装底层异常（如把 SQLException 转为业务异常）、补充上下文信息、或执行完清理逻辑后仍需通知上层失败。
常见错误是盲目 throw e; 而不考虑异常类型是否合适——比如在 service 层直接抛出 IOException，违反了分层契约。
- 用
throw new BusinessException("订单创建失败", e);包装原始异常，保留栈轨迹 - 避免裸写
throw e;（会丢失当前栈帧），改用throw new RuntimeException(e);或显式构造新异常 - 若已记录日志且无需上层处理，可直接 return，不必抛出
throws 声明和实际 throw 的关系容易混淆
throws 是编译器契约，声明“可能抛出这些异常”，但不强制你每次执行路径都抛；而 throw 是运行时动作。两者不一一对应。
例如方法签名写 void process() throws IOException，但内部可能只在特定条件下 throw new IOException()，其余路径正常返回。反过来说，如果 catch 住一个 IOException 后没再抛出，那 throws IOException 就是冗余甚至错误的——编译器不会报错，但语义失真。
立即学习“Java免费学习笔记（深入）”；
- 删掉未被抛出的
throws声明，避免误导调用方 - 检查所有分支路径：是否有
return、throw、还是隐式抛出未捕获异常 - 对于
RuntimeException子类，throws声明可省略，但加了也不违法
用 try-catch-finally 还是 try-with-resources 影响重抛逻辑
资源管理方式决定了异常传播路径是否被覆盖。在 try-with-resources 中，如果 try 块抛异常，且资源 close() 也抛异常，后者会被抑制（suppressed），主异常仍向上抛出——但如果你在 finally 里手动 close() 并 throw，就可能掩盖原始异常。
try (FileInputStream fis = new FileInputStream("a.txt")) {
// 可能抛 IOException
} catch (IOException e) {
throw new BusinessException("读取配置失败", e); // 正确：包装并抛出
}
- 优先用
try-with-resources，它自动处理抑制异常，不用手动catchclose 错误 - 若必须用
finally，确保其中不抛检查异常（checked exception），否则可能吞掉try块的异常 - 不要在
finally里写throw e;——此时e是未定义变量
日志记录后还该不该 throw
记录日志本身不改变异常是否该继续传播的决策。关键看业务语义：日志只是可观测性手段，不是错误处理终点。
典型误操作是写了 log.error("xxx", e); 就以为“处理完了”，结果静默失败，上游一直收不到错误信号。尤其在异步调用、RPC 接口、事务边界处，漏抛异常会导致状态不一致。
- 记录日志 ≠ 处理异常，除非这是兜底的全局异常处理器（如 Spring 的
@ControllerAdvice） - 在 service 方法中，若业务规则校验失败，应抛
BusinessException；若底层 IO 失败，应包装后抛出 - 唯一可不抛的场景：异常纯属监控用途（如降级日志）、或明确属于“预期中的失败”且有替代逻辑（如缓存未命中）
