Java异常信息编写规范与优化建议

异常消息必须包含可定位的上下文，如订单ID、用户ID、接口路径等业务标识，并用具体动作和值替代模糊动词，避免拼接敏感信息、运行时调用易错方法或在getMessage()中塞入堆栈。

异常消息必须包含「可定位的上下文」

Java里抛出的异常如果只写 "Error occurred" 这类泛化信息，排查时根本无法判断是哪个请求、哪条数据、哪个参数出了问题。关键不是“报错了”，而是“在哪错、因何错、谁触发的”。

• 务必包含业务标识：如订单ID、用户ID、接口路径 —— 例如 "Failed to process order #ORD-2024-7890: payment amount is negative"
• 避免模糊动词：“failed”“invalid”要替换成具体动作和值："parseDate('2024-13-01') failed: month must be 1–12"
• 不拼接敏感信息（如明文密码、身份证号），但可保留脱敏后的标识符："user_id=usr_8a2b...f3e1"

不要在异常消息里做逻辑判断或格式化

异常构造阶段不该调用可能失败的方法，比如 new IllegalArgumentException("User " + user.getName() + " not found") 中，若 user.getName() 抛空指针，原始错误就被掩盖了。

• 所有变量值应在抛出前确认非空/有效，或用 Objects.toString(user, "null") 安全转换
• 避免在消息中调用 JSON.stringify()、LocalDateTime.now().toString() 等易出错或带副作用的操作
• 时间戳、ID等应直接传入已计算好的字符串，而非在异常构造器里现场生成

区分 getMessage() 和日志记录内容

异常消息面向开发者调试，日志行面向运维监控，二者职责不同。很多团队把完整堆栈塞进 getMessage()，导致日志重复且难以结构化解析。

• getMessage() 只保留「一句话因果」：如 "Cannot update status from 'PAID' to 'CANCELLED'"
• 详细上下文（参数快照、SQL语句、HTTP头）应通过日志框架单独记录，例如 SLF4J 的 logger.error("Update status rejected", e)
• 若需传递结构化数据给上层处理（如API返回码），应使用自定义异常字段，而非塞进字符串消息

自定义异常类要重写 toString() 吗？

一般不用。JDK 默认的 toString() 已包含类名 + 消息 + 堆栈缩略，够用。强行重写反而破坏标准行为，让 printStackTrace() 或 APM 工具解析异常时丢失关键信息。

• 例外情况：仅当需要在控制台快速显示业务摘要（如运维脚本），且明确知道不会被日志框架捕获时，才考虑重写
• 更稳妥的做法是提供一个 toSummary() 辅助方法，由调用方按需调用
• 切勿在 toString() 中抛异常、访问数据库或远程服务 —— 这会导致 printStackTrace() 自身崩溃

public class OrderStatusTransitionException extends RuntimeException {
    private final String orderId;
    private final String fromStatus;
    private final String toStatus;

    public OrderStatusTransitionException(String orderId, String from, String to) {
        super(String.format("Cannot transition order %s from '%s' to '%s'", orderId, from, to));
        this.orderId = orderId;
        this.fromStatus = from;
        this.toStatus = to;
    }

    // 不重写 toString()，保持默认行为
    public String toSummary() {
        return String.format("[OrderStatus] %s: %s → %s", orderId, fromStatus, toStatus);
    }
}