不能。异常机制专为处理运行时错误设计，而非业务分支跳转；其高开销、干扰jit优化、掩盖真实问题等缺陷，决定了稀有业务路径应使用if、策略模式等显式控制流实现。
不能。异常机制不是为业务分支跳转设计的，用它实现稀有路径跳转属于典型的误用。
异常的本质是错误信号，不是控制流开关
Java、Python 等语言中，异常对象（如 Exception 或其子类）代表的是“运行时意外状况”——比如文件不存在、网络超时、空指针、除零等。JVM 或运行时会中断当前执行栈，触发查找匹配 catch 块的过程。这个过程涉及堆栈遍历、对象创建、上下文保存，开销远高于普通 if 判断或 switch 分支。
- 抛出一次异常的耗时通常是普通方法调用的数十倍甚至百倍
- 频繁或刻意抛异常会显著拖慢性能，且干扰 JIT 编译器的热点优化
- 堆栈信息会膨胀日志，掩盖真实错误，增加运维排查成本
业务分支逻辑应由显式条件判断承载
所谓“低频发生的稀有业务分支”，本质仍是正常业务语义的一部分。例如：
- 用户上传了非标准格式附件 → 应检查
file.getContentType()后走降级处理流程 - 老版本 API 请求到达 → 应解析
header["X-Api-Version"]后路由到兼容处理器 - 风控系统判定为灰度用户 → 应查缓存或配置中心后启用实验功能
这些都不是“程序出错了”，而是“业务规则要求这么做”。用 if、switch、状态机或策略模式表达更清晰、更高效、更易测试。
真正适合用异常的场景很明确
只在以下情况才该抛异常：
- 违反前置条件（如参数为 null、ID 格式非法），且当前层无法继续执行
- 依赖外部资源失败（如数据库连接中断、远程服务不可达），且无本地 fallback
- 检测到数据不一致或状态非法（如订单已支付却收到重复支付请求）
这些场景的共同点是：它表示“当前上下文已无法安全推进”，需要中断、回滚、告警或交由上层决策——而不是“换一条路继续跑”。
替代方案更健壮、更可维护
若想简化稀有分支的编码负担，可考虑：
- 策略注册表：将不同业务路径封装为 Strategy 实现，按条件动态选取
- 事件驱动：发布 “UploadFormatUnusualEvent”，由监听器处理降级逻辑
- Optional + map/flatMap：用函数式链式表达可选路径，避免嵌套 if
- 状态机引擎（如 Spring StateMachine）：显式建模状态转移，含 guard 条件
它们都保持控制流透明、可观测、可单元测试，不会混淆“错误”与“分支”语义。
