用自定义异常替代冗长if-else，核心是显式抛出“校验失败”语义，使主流程聚焦正常路径；需区分业务规则校验与程序逻辑分支，校验方法只检查并抛异常，配合统一异常处理器、Optional等提升可读性与可维护性。
用自定义异常替代冗长的 if-else 判断，核心不是“不用判断”，而是把“校验失败”的语义显式抛出，让主流程聚焦在“正常路径”上，提升可读性与可维护性。
明确区分“业务规则校验”和“程序逻辑分支”
if-else 常被误用于表达业务约束（比如“用户名不能为空”“余额不足不能支付”），这类条件本质是前置校验，不是真正的业务分支。应将其提取为独立校验方法，并在不满足时抛出自定义异常：
- 定义如 InsufficientBalanceException、InvalidOrderStatusException 等语义清晰的异常类，继承 RuntimeException（无需强制 try-catch）或 Exception（需显式处理）
- 校验方法只做一件事：检查 + 抛异常，不返回布尔值，不嵌套 if
- 主服务方法中顺序调用校验方法，再执行核心逻辑——代码变成“先确保合规，再做事”，线性可读
用统一异常处理器收敛错误响应
抛出的自定义异常不应散落在各处 try-catch 中。通过 Spring 的 @ControllerAdvice 或类似机制统一捕获：
- 为每种业务异常映射对应的状态码（如 400 Bad Request）、错误码（如 "BALANCE_INSUFFICIENT"）和用户提示语
- 避免在 Controller 里写 if (e instanceof XxxException) { return error(...) }
- 前端收到结构一致的错误体，无需解析不同字段；后端新增校验只需加异常类 + 处理器映射，不改原有流程
配合 Optional 或 Result 封装，避免空指针干扰主流程
当校验依赖外部查询（如查用户、查订单），可能返回 null。与其用 if (user == null) throw new UserNotFoundException()，不如让 DAO 层直接返回 Optional
- userRepository.findById(id).orElseThrow(() -> new UserNotFoundException(id));
- 这种写法比手动判空更函数式，也自然融入异常驱动风格
- 若需组合多个校验（如“用户存在且状态有效且额度充足”），可用链式调用或单独方法封装，每个环节失败即抛对应异常
注意边界：异常不是万能的控制流替代品
以下情况仍适合 if-else：
- 预期频繁发生的“非错误”分支（如根据消息类型路由到不同处理器）
- 需要精确控制 fallback 行为的场景（如缓存未命中查 DB，查不到再返回默认值）
- 性能敏感路径（异常创建开销略高，但对绝大多数业务系统可忽略）
关键是把“不符合业务规则”当作异常，而不是把“所有条件分支”都包装成异常。
