业务错误应使用自定义 runtimeexception（如 bizexception），避免模糊预期失败与意外崩溃边界，需提供多构造函数支持异常链、错误码解耦及日志友好输出。
为什么不能直接 throw new RuntimeException("xxx")
业务错误不是程序崩溃，用 RuntimeException 会模糊“预期失败”和“意外崩溃”的边界。调用方无法区分是参数错了还是数据库挂了，更没法针对性捕获重试或降级。
- 所有
RuntimeException子类默认不强制捕获，下游容易漏处理，上线后才发现订单创建失败却没日志、没告警 - 框架（如 Spring）对
RuntimeException默认回滚事务，但像“余额不足”这种业务拒绝，不该触发回滚——它根本没改数据库 - 错误码、错误上下文（如订单ID、用户ID）无法结构化携带，日志里只剩一串字符串，排查时得靠猜
自定义异常类必须重写哪些构造函数
Java 异常链和日志打印依赖构造函数签名。只写一个带 String 的构造函数，会导致上游用 new BizException("xxx", e) 时丢失原始异常栈，调试时看不到根因。
- 必须提供
BizException(String message)—— 用于简单提示 - 必须提供
BizException(String message, Throwable cause)—— 用于包装底层异常（如 DAO 层抛出的SQLException） - 建议加
BizException(ErrorCode code, String message)—— 把错误码和消息解耦，方便国际化或前端映射
示例：
public class BizException extends RuntimeException {<br> private final ErrorCode code;<br><br> public BizException(String message) {<br> super(message);<br> this.code = ErrorCode.UNKNOWN;<br> }<br><br> public BizException(String message, Throwable cause) {<br> super(message, cause);<br> this.code = ErrorCode.UNKNOWN;<br> }<br><br> public BizException(ErrorCode code, String message) {<br> super(message);<br> this.code = code;<br> }<br>}
ErrorCode 枚举要不要放 HTTP 状态码
不要。HTTP 状态码是协议层概念，和业务语义无关。把 400 塞进 ErrorCode 枚举，会导致 RPC 调用（如 Dubbo、gRPC）或消息队列场景下误用——它们根本不走 HTTP。
立即学习“Java免费学习笔记（深入）”；
- 枚举只管业务维度：比如
ORDER_NOT_FOUND、INSUFFICIENT_BALANCE，值用纯数字（如1001、1002），和协议解耦 - HTTP 状态码由 Controller 层统一映射：Spring MVC 用
@ControllerAdvice+@ExceptionHandler根据ErrorCode决定返回400还是409 - RPC 场景下，这个枚举可序列化传给下游，对方按码做本地化处理，不用硬编码状态码
log.error() 里要不要打印 e.printStackTrace()
不要。SLF4J 的 logger.error(msg, e) 已自动输出完整栈，多打一次 e.printStackTrace() 会让日志重复、错行，还可能因线程竞争导致日志混乱。
- 正确写法：
log.error("创建订单失败，orderNo={}", orderNo, ex);—— 消息清晰，异常对象作为参数传入 - 如果异常是自定义的，确保
getMessage()返回的是业务友好文案（如“库存不足”，而非“java.lang.NullPointerException”） - 敏感字段（如手机号、身份证号）要在
getMessage()中脱敏，别等日志进 ELK 才想起来过滤
复杂点在于：异常类本身要轻量，别在构造时查数据库或远程调用；错误码枚举要集中管理，避免散落在各个 service 里硬编码；还有，别让团队成员开始争论“该继承 Exception 还是 RuntimeException”——只要约定好“所有业务异常都继承 RuntimeException，但必须可被捕获和识别”，就比纠结检查异常更有实际价值。
