java异常不适合常规流程控制，专用于处理意外情况；其性能差、可读性低且违背设计初衷，应仅在无法预判、需立即中断并反馈的场景（如外部依赖失败）中使用。
Java异常不适合用于常规流程控制，它专为处理意外、异常情况而设计。用异常做逻辑分支不仅性能差、可读性低，还违背了异常机制的设计初衷。
异常的本质是“非预期事件”
Java中Exception和Error代表程序运行中本不该发生、需要特殊处理的问题，比如文件不存在（FileNotFoundException）、网络超时（SocketTimeoutException）、数组越界（ArrayIndexOutOfBoundsException）等。这些不是业务常态，而是执行路径的中断信号。
- JVM对异常处理有额外开销：填充栈轨迹、查找catch块、展开调用栈，比普通if判断慢10倍以上
- 把try-catch当if-else用，会让代码意图模糊——读者无法分辨这是容错逻辑，还是兜底补救
- 过度抛出受检异常（如自定义BusinessException）会污染方法签名，迫使调用方冗余处理
哪些场景属于合理使用异常
真正该用异常的地方，是那些程序无法通过前置判断完全规避、且发生后需立即中止当前流程并向上反馈的情况：
- 外部依赖失败：数据库连接断开、HTTP接口返回500、序列化第三方数据格式错误
- 资源不可用：打开文件被占用、内存分配失败（OutOfMemoryError虽属Error，但体现系统级异常）
- 违反契约约束：传入null参数且方法明确要求非空（可用Objects.requireNonNull()触发NullPointerException）
替代异常的流程控制方式
日常业务判断应优先使用清晰、轻量的结构：
立即学习“Java免费学习笔记（深入）”；
- 用Optional
表达可能为空的返回值，避免null检查与NullPointerException混用 - 用状态码或枚举封装操作结果（如Result.success(data) / Result.fail("库存不足")），调用方显式判断isSuccess()
- 对可预知的分支（如用户角色不同跳转不同页面），直接用if/switch或策略模式，不引入异常流
边界模糊时的判断原则
当不确定某情况是否该抛异常，问自己三个问题：
- 这个情况在正常业务流程中是否频繁发生？（高频=不该用异常）
- 能否在操作前通过简单条件判断提前拦截？（能拦截=用if）
- 一旦发生，是否意味着当前操作必须终止、且调用方需要立刻感知并决策？（必须中断+需响应=可用异常）
基本上就这些。异常不是语法糖，而是安全网——网住真正的意外，别拿它当梯子去够本该走的台阶。
