Java自定义异常结合状态机处理业务异常，核心是将异常类型作为显式状态跃迁信号，每种异常承载明确业务语义与后续动作意图，实现错误处理从被动兜底变为主动编排。
Java 自定义异常结合状态机处理业务异常，核心在于把“异常类型”作为状态跃迁的显式信号，让每种异常承载明确的业务语义和后续动作意图，而不是笼统地表示“出错了”。这本质上是用异常驱动状态流转，使错误处理从被动兜底变为主动编排。
用自定义异常定义状态分支点
每个业务异常类对应一个可识别、可决策的状态出口。比如订单系统中：
- OrderAlreadyPaidException → 表示“已支付”终态，后续只能查单或退款，不可重复支付
- InventoryInsufficientException → 表示“库存不足”中间态，触发降级（如启用预售）、通知补货或返回兜底商品
- InvalidPaymentChannelException → 表示“渠道不可用”，需切换支付方式并重试，不终止流程
这些异常不是随便起名，而是直接映射业务状态图里的节点，catch 块就自然成为该状态下的处理入口。
在 try-catch-finally 中实现状态跃迁
try 块执行主路径（如“尝试扣减库存”），一旦抛出自定义异常，JVM 立即中断当前流程，跳转至对应 catch —— 这就是一次确定性的状态转移。
立即学习“Java免费学习笔记（深入）”；
- catch 块不做泛化日志，而是执行该状态专属逻辑：更新订单状态字段、发消息、调用补偿服务
- finally 不写业务代码，只做终态保障：释放分布式锁、关闭数据库连接、清除线程局部变量
- 若需状态再跃迁（如库存不足时自动走预售流程），在 catch 内调用新方法，而非 throw 新异常向上推诿
配合全局处理器统一收口与透传
在 Spring MVC 中，用 @ControllerAdvice 捕获自定义异常，可集中做三件事：
- 将异常码（如 “ORDER_PAYED_001”）和业务提示语返回前端，避免暴露堆栈
- 根据异常类型决定是否记录审计日志、触发告警或上报链路追踪（如 InventoryInsufficientException 需立即告警）
- 对部分异常（如网络超时类）做透明重试封装，对另一些（如参数非法）直接拦截并返回 400
这样，控制器层保持干净，状态决策下沉到 service 层的异常定义与捕获逻辑中。
设计自定义异常时的关键细节
真正支撑状态机运转的，不只是类名，还有结构设计：
- 继承 RuntimeException，避免强制 throws 干扰状态流表达（业务异常本就不该被上层“忽略”）
- 必带 error code 字段，用于前端展示、监控分类、多语言适配
- 支持携带上下文对象（如 orderId、skuId），方便状态处理时精准操作
- 构造器保留 cause 参数，确保原始异常链不丢失，便于根因分析
例如：new InventoryInsufficientException("INV_STOCK_002", "SKU-10086 库存只剩 0 台", skuId)，既声明了状态，又提供了后续动作所需数据。
