自定义异常应通过构造函数传入上下文字符串并保留super(message)，推荐添加errorCode字段和getter，避免依赖initCause()或setStackTrace()补充信息，全局异常处理需透传message和errorCode。
Java中抛出自定义异常时如何设置详细信息
直接在构造函数里传入带上下文的字符串，是最常用也最有效的方式。Java所有内置异常都支持 String 构造参数，自定义异常继承 Exception 或 RuntimeException 后，只要不覆盖父类构造方法，就能天然获得这个能力。
常见错误是只写空参构造、或只重载了带 Throwable 的构造，结果调用 getMessage() 时返回 null 或空字符串。
- 务必保留
super(message)调用，哪怕只是透传 - 如果需要组合多个字段（如错误码 + 用户ID + 时间戳），建议在自定义异常类中封装一个静态工厂方法，避免每次 new 时手动拼接
- 不要在 message 中硬编码敏感数据（如密码、token），生产环境应脱敏或记录到日志而非异常消息体
自定义异常类要不要加错误码字段
要，尤其在分布式系统或对外提供 SDK 的场景下。仅靠 getMessage() 无法结构化识别问题类型，而 HTTP 状态码、RPC 错误码、前端提示文案都依赖稳定可枚举的错误标识。
典型设计是在异常类中添加 private final String errorCode 字段，并提供 getter；构造时强制传入，同时把 error code 和 message 组合成最终异常描述：
立即学习“Java免费学习笔记（深入）”；
public class BizException extends RuntimeException {
private final String errorCode;
public BizException(String errorCode, String message) {
super("[" + errorCode + "] " + message);
this.errorCode = errorCode;
}
public String getErrorCode() { return errorCode; }
}
注意：不要把 error code 放进 getMessage() 的开头就完事——它只是展示用，真正做逻辑分支时应调用 getErrorCode()，否则后续想提取或替换格式会很被动。
为什么不能只靠 initCause() 或 setStackTrace() 来补充信息
因为这两者都不影响 getMessage() 返回值，而多数日志框架（如 Logback、Log4j）默认只打印 toString()，即 类名 + ": " + getMessage()。如果你只调用 initCause(e)，堆栈里确实能看到根因，但日志第一行仍可能显示“null”或无意义的默认提示。
更隐蔽的问题是：有些监控系统（如 SkyWalking、Pinpoint）只采集异常类名和 message，忽略 cause 链。一旦没在 message 里写清关键上下文，排查时就得翻原始日志或全链路追踪，效率大幅下降。
-
initCause()适合包装底层异常，但必须配合有意义的 message 使用 -
setStackTrace()几乎没必要手动调，JVM 抛出时已自动填充；强行修改反而干扰调试定位 - 真正需要“补充信息”的地方，应该在构造时就塞进 message，或通过扩展字段暴露（如
getUserId()、getOrderId()）
Spring Boot 中全局异常处理对 message 的影响
使用 @ControllerAdvice + @ExceptionHandler 时，很多人以为只要 catch 到异常，就可以在 handler 里重新组装响应体，从而“绕过”原始 message 设计。但实际线上问题常出现在两个环节：
- 全局 handler 没有透传原始
getMessage()，而是统一返回 “操作失败”，丢失关键线索 - JSON 响应体里把整个异常对象序列化出去（含 stackTrace），既暴露内部结构，又违反最小披露原则
推荐做法是：在 handler 中提取 e.getMessage() 和 e instanceof BizException ? ((BizException) e).getErrorCode() : "UNKNOWN"，再封装成标准响应结构。message 不做二次加工，除非明确要做国际化或前端友好转换——那也该走 i18n key，而不是字符串拼接。
真正容易被忽略的是：当异常从 FeignClient 或 Dubbo 远程调用抛回时，message 可能已被序列化/反序列化截断或转义，此时依赖 message 做判断极不可靠，必须靠 error code + 业务字段。
