如何让异常对象携带额外上下文信息（cause vs context）_技术教程

异常需区分cause（根本原因，用于异常链和栈追踪）与context（执行上下文，用于诊断日志）；cause须通过构造函数显式设置，context应作为只读字段存于自定义异常中并结构化输出。

异常对象携带额外上下文信息，关键在于区分 cause（根本原因） 和 context（执行上下文）：前者用于构建异常链、支持栈追踪回溯；后者用于辅助诊断、日志记录或调试，但不参与异常传播逻辑。

用 cause 表达嵌套异常（真正的“因为”）

当一个异常由另一个异常引发时，应通过构造函数的 cause 参数（如 Java 的 Throwable(Throwable cause)，Python 的 raise NewError() from original_exc）显式关联。这会让运行时保留原始异常的完整栈，调用 getCause() 或 __cause__ 可获取它，打印异常时也会自动显示 “Caused by”。

Java 示例：throw new IllegalArgumentException("Invalid user ID", originalException);
Python 示例：raise ValueError("Processing failed") from exc
避免手动拼接消息代替 cause——那样会丢失栈、无法被工具识别、破坏异常分类逻辑

用 context 字段或属性附加诊断信息（当前“在哪、谁、什么状态”）

cause 解决“为什么发生”，context 解决“当时发生了什么”。推荐在自定义异常类中添加只读字段（如 userId, requestId, inputData），初始化时传入并存为实例属性。

Java：定义 public final String requestId;，在构造器中赋值
Python：在 __init__ 中设 self.request_id = request_id
重写 toString() 或 __str__ 时包含这些字段，方便日志直接输出上下文
不建议把 context 塞进 message 字符串——难解析、易重复、干扰错误模式匹配

避免混淆 cause 与 context 的常见错误

把本该是 context 的信息（如用户ID、时间戳）当作 cause 抛出，会导致异常链失真；反过来，把底层 I/O 异常仅作为 context 记录而不设为 cause，则丢失关键根因线索。

❌ 错误：捕获 IOException 后创建新异常时，用 message += "user=123" 而不设 cause
✅ 正确：以 IOException 为 cause 构造新异常，并单独保存 userId 字段
❌ 错误：为记录请求 ID，包装异常时用 new RuntimeException(original, requestId)——把 context 当 cause
✅ 正确：自定义异常类同时持有 cause（父异常）和 requestId（context 字段）