异常是java中结构化的goto控制流，jvm通过athrow指令和异常表实现跳转；滥用异常替代条件判断性能差且语义错位；checked异常强制编译期处理控制流分支；finally中return会覆盖try/catch返回值。
异常在 Java 中不是“意外”，而是被设计成控制流的合法分支——它和 if、switch 一样，是程序主动选择执行路径的方式。
为什么 throw 和 catch 本质是 goto 的结构化表达
Java 虚拟机层面没有“异常对象”的概念，只有 athrow 指令和异常表（exception table）。JVM 查找匹配的 catch 块，本质上是在当前方法的异常表中做范围匹配和类型比对，找到后直接跳转到对应字节码位置。这和 goto 逻辑一致，只是被语法封装得更安全。
-
try块定义了“可能中断的代码段”，不是保护罩，而是划定跳转起点范围 -
catch是显式声明的跳转目标，不是被动响应，而是主动接管控制权 -
finally不是“收尾动作”，而是无论是否发生跳转都必须执行的固定汇入点（JVM 会复制其字节码到每个出口）
不要用异常替代常规条件判断
常见反模式：Integer.parseInt 抛 NumberFormatException 来判断字符串是否为数字。这不是异常的本意，而是把控制流让渡给 JVM 的错误处理机制，代价高且语义错位。
- 异常抛出涉及栈展开、对象创建、异常表查找，比
Character.isDigit循环慢 10–100 倍 - JIT 编译器对频繁抛异常的路径会去优化（deoptimization），导致性能雪崩
- 调用方无法静态识别该“异常路径”是业务逻辑分支（比如“用户输入非法”），还是真错误（比如“配置文件损坏”）
checked 异常强制你暴露控制流分支
IOException 必须声明或捕获，不是为了“防止出错”，而是迫使你在编译期就决定：这条异常路径是继续向上推（throws），还是就地消化（try-catch），或是转换为更上层语义（throw new ServiceException(...)）。
立即学习“Java免费学习笔记（深入）”；
- 不写
throws或catch就编译失败 → 控制流分支不可忽略 - 但滥用会导致“异常污染”：DAO 层的
SQLException被一路透传到 Controller，破坏分层语义 - 合理做法是：在边界处（如 service 方法入口）将底层异常转为业务异常，隐藏技术细节
finally 中的 return 会吃掉 try/catch 的返回值
这是最易被忽略的控制流覆盖行为。JVM 规范明确：只要 finally 里有 return，就终止当前方法，直接返回其值，无论 try 或 catch 中是否已有返回准备。
public static String test() {
try {
return "try";
} catch (Exception e) {
return "catch";
} finally {
return "finally"; // ← 实际返回这个，前两个被丢弃
}
}
这种写法等价于在所有分支末尾无条件插入跳转指令——它不是“确保执行”，而是“强行劫持返回”。真要清理资源，请用 try-with-resources 或只在 finally 中写关闭逻辑，绝不放 return。
