Java中重新抛出异常需保留原始异常cause、增强业务语义、补充上下文，避免丢堆栈或掩盖根因；典型场景包括转译为业务异常、添加订单ID等字段、统一异常类型；禁用仅log后throw e、丢cause的RuntimeException、finally抛异常等错误做法。
Java中重新抛出异常不是随便写的，关键看你想传递什么信息、由谁来处理、是否需要补充上下文。直接throw e;可能丢掉原始堆栈，用throw new XxxException(..., e);才能保留根因。
该重新抛异常的典型场景
以下情况建议重新抛出（或包装后抛出）：
- 当前层无法处理，但能提供更明确的业务语义：比如DAO层捕获了JDBC SQLException，不应暴露数据库细节，而应转为自定义的DataAccessException，并保留原异常作为cause
- 需要补充上下文信息便于排查：例如在处理用户订单时发生空指针，可在catch里构造新异常，附带orderId、userId等字段，再把原始异常传进去
- 统一异常类型，简化上层调用逻辑：服务接口约定只抛BusinessException，那么各子模块内部无论遇到IO异常、校验失败还是远程调用超时，都应转换为BusinessException并设cause
- 拦截并增强受检异常的语义：比如FileInputStream构造可能抛FileNotFoundException，但业务上更关心“配置文件缺失”，此时可包装为ConfigLoadException
不该简单重抛的常见错误
这些做法会削弱异常的诊断价值：
-
捕获后只写log就
throw e;：没加任何新信息，又没做清理，相当于白抓；不如不捕获，让上层统一处理 -
用
new RuntimeException(e.getMessage())重抛：丢失了原始异常类型和完整堆栈，cause也没设，等于把根因“删掉了” - 在finally里抛异常：如果try块已抛异常，finally再抛会覆盖原异常，导致真实问题被掩盖
- 对非受检异常过度包装：比如把NullPointerException包装成自定义异常再抛，通常没必要——它本就是程序bug，应修复而非掩盖
推荐的再抛写法与技巧
核心原则是：保持cause链不断、语义更准、堆栈不丢。
立即学习“Java免费学习笔记（深入）”；
-
优先使用带cause的构造器：
throw new ServiceException("订单创建失败", e);—— 多数标准异常和自定义异常都支持 -
自定义异常时务必提供cause构造器，并在所有public构造器中调用
super(message, cause) -
需要添加字段信息？用构造器参数+cause：比如
new OrderProcessException(orderId, "库存不足", e)，在toString()或日志中一并输出 - 避免在catch里吞掉异常又不抛出：除非你100%确定这是可忽略的噪音（如某些定时任务中的临时网络抖动），否则至少要记录warn日志
关于异常链与日志打印的小提醒
即使正确设置了cause，如果日志框架只打印e.toString()，依然看不到深层堆栈。确保：
- 用
log.error("msg", e)而不是log.error("msg: " + e) - 检查日志配置是否启用
%ex或%throwable模式输出完整堆栈 - 必要时用
Throwable.printStackTrace()辅助调试（仅限开发环境）
异常再抛不是语法技巧，而是责任划分和信息传递的设计决策。抛得清楚，修得才快。
