catch-throw-new 会丢失原始堆栈是因为未传递 cause 参数，导致异常链断裂；正确做法是 Java 用带 Throwable 的构造函数、Python 用 raise ... from e 显式关联原因。
为什么 catch-throw-new 会悄悄吃掉原始堆栈
当你在 Java 或 Python 中捕获一个异常后，直接 throw new XxxException("xxx")，原始异常的完整 traceback 就断了。日志里只剩新异常的一行消息，底层到底是 NullPointerException 还是 SQLException，完全看不出来。
这不是“没记录”，而是“主动擦除”——你用新异常覆盖了旧异常的因果链。
- 常见错误现象：线上报错只有
BusinessException: 订单创建失败，但查不到数据库连接超时或字段为空的原始根因 - Java 场景：DAO 层抛出
SQLException，Service 层 catch 后throw new ServiceException("创建订单异常")，没传cause - Python 场景：
except ValueError: raise RuntimeError("解析失败")，没加from e，__cause__为空 - 后果：排查时间翻倍，SRE 只能靠猜，监控系统无法归因
raise from 和 init(…, cause=e) 是怎么救场的
它们不是语法糖，是显式声明“这个错是因为那个错才发生的”——把断裂的调用链重新焊上。
Python 的 raise RuntimeError("转换失败") from e 会让 traceback 显示两段堆栈，并标注 The above exception was the direct cause；Java 的 new ServiceException("创建失败", e) 则让 e.getCause() 可追溯。
- 必须传
cause参数，不能只传 message：Java 构造函数要选带Throwable的重载，Python 要用from语法 - 避免多层包装却不传 cause：比如 A 层 catch 后包装成 BException，B 层又 catch 再包装成 CException，但中间某次漏了
cause，链就断了 - 日志打印时必须用
log.error("msg", e)，而不是log.error("msg " + e)，否则只输出 toString()，丢掉 stacktrace
什么时候该用 from None 或不设 cause
不是所有场景都要保留原始异常。当你明确想隐藏实现细节、防止暴露底层技术栈（比如把 RedisConnectionException 包装成统一的 ServiceUnavailableException 并屏蔽 Redis 相关信息），才考虑切断链路。
- Python：用
raise ServiceUnavailableError("服务暂时不可用") from None，traceback 不再显示原始异常 - Java：用
new ServiceUnavailableException("服务暂时不可用")（无 cause 构造器），或显式传null - 注意：这属于主动脱敏，不是偷懒省事；若未加说明，后续人会误以为“这里本就没有底层异常”
- 反模式：在 DAO → Service → Controller 链路中，仅 Controller 层做
from None是合理的，但 Service 层也这么干，就等于主动放弃诊断权
自定义异常基类怎么设计才不白封装
很多团队定义了 BaseException，却只塞了个 errorCode 和 message，结果每层都 new 一次，cause 依然空着——封装成了形式主义。
- 基类必须提供带
Throwable cause的构造函数，并透传给父类super(message, cause) - 错误码建议用枚举（如
ErrorCode.USER_NOT_FOUND），别用字符串硬编码 - 工具类如
Asserts.notNull(obj, ErrorCode.PARAM_NULL)内部 throw 时也要带 cause（如果校验逻辑本身可能触发异常） - 避免“封装即安全”错觉：把
password写进异常 message 里，再怎么封装也是泄露；敏感字段得在构造时过滤，不是靠封装层级藏住
异常链不是加个 from e 就完事，它要求每一层都意识到自己处在哪一环——是转发者，还是终结者。最容易被忽略的，是中间层开发者觉得“我只要往上抛就行”，却忘了抛的时候得把手里那截链条牢牢焊上去。
