Java业务异常应继承RuntimeException，因其代表可预期的业务失败，无需强制捕获；需按领域命名并隔离异常类，提供可读错误码字符串，于领域逻辑内层抛出，避免滥用catch控制流程。
业务异常该继承 RuntimeException 还是 Exception
Java 业务异常通常应继承 RuntimeException，而非 Exception。这不是风格偏好，而是语义约束：业务异常代表「流程中可预期的、非系统故障的失败」，比如余额不足、订单已取消、参数校验不通过——它们不该强制调用方用 try-catch 或声明 throws，否则会污染业务主干逻辑，让正常路径被异常处理淹没。
若继承 Exception，编译器强制上层处理，结果往往是泛化捕获：catch (Exception e) { log.error("", e); }，丢失业务语义；或草率抛出 throws Exception，把责任甩给更上层，破坏分层契约。
例外情况极少：仅当某类业务规则必须被所有调用链显式决策（如金融风控中的“需人工复核”状态），才考虑受检异常，但此时更推荐返回 Result 或状态枚举，而非异常。
如何命名和组织业务异常类
命名要直指业务动因，避免泛化词如 BusinessException 或 ServiceException。每个异常类对应一个明确的业务失败场景：
立即学习“Java免费学习笔记（深入）”；
-
InsufficientBalanceException（不是AccountException） -
OrderAlreadyShippedException（不是OrderException） InvalidPromotionCodeException
组织上建议按领域包隔离，例如：
com.example.order.exception.OrderAlreadyPaidException com.example.payment.exception.PaymentTimeoutException
不建议统一放在 exception 包下堆砌几十个类——难以定位，也削弱了领域边界感。同时，避免为省事复用同一个异常类传不同 message，这会让下游无法做精准类型判断（如重试策略、告警过滤）。
构造函数与错误码设计是否必要
必须提供带错误码的构造函数，且错误码不应是纯数字（如 1001），而应是可读字符串常量，例如：
public class InsufficientBalanceException extends RuntimeException {
public static final String CODE = "ORDER_BALANCE_INSUFFICIENT";
public InsufficientBalanceException(String orderId, BigDecimal required) {
super(String.format("Order %s requires %s but balance is insufficient", orderId, required));
}
}
原因有三：
message 仅用于开发调试，不参与对外暴露；不要在 message 里拼接敏感数据（如用户身份证号），也不要用它传递结构化信息（如余额数值应作为字段保留，而非塞进字符串）。
抛出时机与 catch 的常见误用
业务异常应在**领域逻辑最内层**抛出，即规则判定发生的那一刻。例如库存扣减时发现 stock ，就立刻抛 InsufficientStockException，而不是返回 false 让外层再包装。
反模式包括：
- 在
Controller层统一用if (!result.isSuccess()) throw new BusinessException()—— 把领域规则降级为 if 判断，丧失异常的语义穿透力 - 在
catch中吞掉业务异常再抛新异常：catch (InsufficientBalanceException e) { throw new ServiceException(e); }—— 销毁原始错误码和上下文 - 用
try-catch捕获自己的业务异常做“流程控制”，比如try { placeOrder() } catch (OrderAlreadyExistsException e) { sendConfirmEmail(); }—— 这属于滥用异常机制，应改用返回值或状态机
真正需要 catch 业务异常的场景极少，通常是跨系统调用后做补偿（如支付失败回滚库存），且必须重新抛出原异常或封装为更上层语义的新异常，保留 cause。
业务异常设计最难的部分，往往不是写几个类，而是团队能否在代码审查中守住“异常即业务事实”的共识——一旦开始用异常绕过 if/else，或用 message 替代错误码，整套机制就迅速退化为日志打印工具。
