抛出异常后当前方法立即终止，throw后代码不执行；无匹配catch则异常上抛至线程终止；throw是运行时中断，throws仅编译声明；finally中return或throw会覆盖原异常或返回值；checked异常强制处理，unchecked则否；new异常开销大，慎用在高频路径。
抛出异常后当前方法立即终止
调用 throw 语句后，当前方法剩余代码不再执行，控制权直接交还给调用栈中最近的匹配 catch 块。即使 throw 后面跟着 return 或变量赋值，这些语句也永远不会运行。
- 常见错误：在
throw后写清理逻辑（如关闭资源），结果根本不会执行 —— 应改用finally或 try-with-resources - 若无匹配
catch，异常沿调用栈向上抛，直到被处理或导致线程终止（如main方法未捕获，程序退出） -
throw不等于throws：throws是声明，只影响编译检查；throw是运行时动作，真实中断流程
try-catch-finally 中的 return 与异常共存行为
当 try 或 catch 块中有 return，同时 finally 也存在，Java 会先记住 return 的值，再执行 finally；若 finally 里也有 return，则覆盖原返回值 —— 这同样适用于异常场景。
- 如果
try抛出异常，且catch未重新抛出，但finally中又抛出新异常，则原始异常被丢弃，调用方只看到finally的异常 -
finally中避免return或再次throw，否则会掩盖关键错误上下文 - 示例：
try { throw new RuntimeException("A"); } catch (Exception e) { System.out.println("handled"); } finally { throw new RuntimeException("B"); }→ 外部只能捕获 "B"
checked 异常强制中断编译，unchecked 则不然
Exception 及其子类（不含 RuntimeException）是 checked 异常，编译器要求你必须处理（try-catch 或声明 throws），否则编译失败；而 RuntimeException 及其子类（如 NullPointerException、ArrayIndexOutOfBoundsException）不强制，可直接抛出并中断执行。
- 不要用
throw new RuntimeException("...")替代本该声明的 checked 异常，这会让调用方失去提前防御的机会 - 自定义业务异常建议继承
Exception（需显式处理）或RuntimeException（表示不可恢复的编程错误），选型取决于是否希望强制调用方响应 - 过度使用
throws Exception会削弱接口契约 —— 应明确列出可能抛出的具体异常类型
异常对象本身携带执行路径信息，但构造开销不可忽视
每次 new 一个异常（如 new IOException()），JVM 都会采集当前线程栈轨迹（fillInStackTrace()），这个操作耗时明显，尤其在高频路径（如循环内、日志判断分支）中容易成为性能瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 日志场景下，若只是记录“此处可能出错”，不必真抛异常；可用
logger.debug("skip due to invalid id: {}", id)替代throw new IllegalArgumentException(...) - 某些框架（如 Lombok 的
@SneakyThrows）能绕过编译检查，但不改变运行时开销 —— 异常仍被创建和抛出 - 极端性能敏感场景（如网络协议解析循环），可复用异常实例（注意线程安全），或使用无栈异常（
new MyException().setStackTrace(new StackTraceElement[0])），但会丢失调试线索
finally 对异常流的劫持，以及 fillInStackTrace() 在非错误路径上的隐性成本 —— 它们不会报错，但会让问题更难定位、让吞吐量悄然下降。 
