不建议用异常驱动实现复杂FSM的错误流转，因异常非控制流机制，会导致性能开销大、语义失真、静态分析失效及堆栈污染；应采用状态+事件驱动模型、成熟FSM库或显式错误状态设计。
不建议在 Java 中用异常驱动实现复杂有限状态机（FSM）的错误流转。
异常不是控制流机制
Java 的异常设计初衷是处理非预期、偶发、无法继续正常执行的错误情况，而非替代 if/else 或状态跳转逻辑。用 try/catch 实现状态迁移会带来严重问题：
- 性能开销巨大：抛出和捕获异常涉及栈遍历、填充堆栈跟踪，比普通方法调用慢 100 倍以上
- 语义失真：状态“切换”被伪装成“错误”，违反直觉，让代码难以理解、调试和维护
- 静态分析失效：IDE、编译器、SonarQube 等工具会误报大量“未处理异常”或“空 catch 块”，掩盖真实风险
- 堆栈污染：正常业务流程中频繁抛异常，导致日志和监控中充斥虚假错误信号
真正适合复杂 FSM 的方案
针对“极其复杂的 FSM 错误流转”，应选择语义清晰、可扩展、可观测的方案：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
状态+事件驱动模型：用枚举定义状态（
State.IDLE,State.PROCESSING），用事件对象（Event.Timeout,Event.ValidationFailed）触发转移；配合状态转移表（Map>）或策略模式 - 使用成熟 FSM 库：如 Spring State Machine（支持状态持久化、事件监听、条件转移、错误处理钩子）或 stateless4j（轻量嵌入式）
-
显式错误状态与恢复路径：为错误设计专用状态（
State.VALIDATION_ERROR,State.RETRY_PENDING），并提供明确的retry()、cancel()、escalate()方法，而非靠异常“跳”过去
如果必须拦截/转化异常用于状态响应
可在 FSM 外层做一层薄薄的异常适配，但绝不让异常穿透状态逻辑本身：
立即学习“Java免费学习笔记（深入）”；
- 在状态处理器内部捕获业务异常（如
PaymentException），将其映射为预定义事件（Event.PaymentFailed） - 由 FSM 引擎根据当前状态 + 该事件，查表决定进入
State.PAYMENT_FAILED并触发对应动作（记录日志、通知用户、启动补偿） - 全局统一异常处理器（如 Spring 的
@ControllerAdvice）只负责 HTTP 层转换，不参与状态决策
用异常跳转状态，就像用消防栓浇花——能出水，但浪费、危险、根本不是它的用途。把状态逻辑交还给状态机，把异常留给真正的意外。
