Java自定义异常应通过final字段封装订单号、用户ID等结构化上下文，提供多参构造方法和getter，并支持Builder模式提升可维护性。
Java 中通过自定义异常传递详细错误上下文，核心是让异常类携带可读、可追溯、结构化的额外信息，而不是只依赖 getMessage() 的字符串拼接。关键在于：继承 Exception（或 RuntimeException），重载构造方法，封装上下文字段，并提供安全、易用的访问方式。
设计带上下文字段的自定义异常类
不要只靠 message 字符串塞一堆信息，而是用成员变量明确承载上下文。例如处理订单失败时，需要订单号、用户ID、失败阶段、原始错误码等：
- 定义 final 字段存储上下文数据（如
private final String orderId;） - 提供含上下文参数的构造方法，把业务关键信息传入并赋值
- 为每个上下文字段提供 getter 方法，方便日志、监控或上层决策使用
- 重写
toString()或新增toContextString()方法，统一格式化输出（避免在 getMessage 中混杂业务逻辑）
构造方法链式支持多种调用场景
实际使用中，调用方可能只知部分上下文，或需兼容标准异常用法。建议提供多组构造方法：
-
MyBusinessException(String message)—— 兼容基础用法 -
MyBusinessException(String message, String orderId, Long userId)—— 主业务上下文 -
MyBusinessException(String message, Throwable cause, String orderId, int errorCode)—— 支持异常链 + 上下文 - 所有构造方法中，调用
super(message, cause)确保堆栈和 cause 正常传递
在抛出和捕获时正确使用上下文
抛出时不丢失信息，捕获时不盲目吞掉上下文：
立即学习“Java免费学习笔记（深入）”；
- 抛出时直接传入实时业务数据：
throw new PaymentFailedException("余额不足", orderId, userId, "BALANCE_INSUFFICIENT"); - 捕获后不要仅打印
e.getMessage()，而应组合上下文日志：log.error("支付失败[order={}][user={}][code={}]", e.getOrderId(), e.getUserId(), e.getErrorCode(), e); - 若需包装底层异常（如 DAO 抛出 SQLException），用带 cause 的构造方法，确保原始异常链完整
进阶：用 Builder 模式提升可读性与扩展性
当上下文字段较多（>5 个）或存在可选字段时，Builder 模式更清晰、不易错位：
- 定义静态内部类
Builder，提供 fluent 接口（如.orderId("ORD-123").userId(1001).stage("AUTH").build()） - Builder 构造最终异常实例，强制校验必填字段（如 orderId 不为空）
- 避免长参数列表导致的调用混乱，也便于未来新增上下文字段而不破坏兼容性
