异常向上抛出是未捕获异常沿调用栈自动向上传递的过程，从methodC逐层上浮至main，最终由JVM处理；throws仅为编译期契约声明，throw才是实际抛出动作。
异常向上抛出就是“没人在现场处理，就交给上一级”
Java里异常向上抛出不是主动“发送”，而是被动“未捕获后的自然传递”。只要一个方法里发生了异常，且当前 try 块没有匹配的 catch，也没有用 finally 拦截并吞掉（比如用 return 覆盖），这个异常对象就会自动沿着调用栈往上调用者方向“冒泡”——就像水里没按住的气泡一样，一层层往上浮，直到有人接住或浮出水面（JVM）为止。
- 从最内层方法（比如
methodC()）开始，一旦抛出异常且未被本层catch，立刻中断执行，跳回调用它的地方（methodB()） -
methodB()若也无对应catch，异常继续上浮到methodA() - 最终若传到
main()还没人处理，JVM 接收并打印堆栈、终止程序 - 整个过程不依赖
throws声明——即使没写throws，非受检异常（如NullPointerException）照样能向上抛；而受检异常（如IOException）必须显式声明或捕获，否则编译不通过
throws 不是“抛出动作”，只是“提前贴个告示”
throws 出现在方法签名末尾，本质是编译器强制的契约：告诉所有调用者，“我这个方法可能会甩出这些异常，请你做好准备”。它本身不触发任何运行时行为，也不影响异常是否真的发生——真正抛出异常的是 throw 语句或底层 JVM。
- 只对受检异常（
Exception及其子类，但非RuntimeException）有强制约束；写不写throws RuntimeException编译器不管 - 如果方法内部调用了另一个声明了
throws IOException的方法，又不想自己try-catch，就必须在自己方法上也加throws IOException，否则编译失败 - 多个异常用逗号分隔：
public void loadConfig() throws IOException, ClassNotFoundException - 不能只写父类却抛子类异常（比如声明
throws Exception却抛SQLException）——除非子类是父类的合法子类型，否则编译报错
throw 是唯一真正“扔出去”的动作
throw 是运行时指令，执行到它那一行，当前方法立刻停止，把新建的异常对象交出去。它必须后跟一个 Throwable 实例（不能是字符串、数字等任意对象）。
public void withdraw(double amount) {
if (amount < 0) {
throw new IllegalArgumentException("取款金额不能为负: " + amount); // ✅ 正确：抛出 Throwable 子类实例
}
if (amount > balance) {
throw new IllegalStateException("余额不足，当前余额: " + balance); // ✅ 合理使用业务异常
}
balance -= amount;
}
- 抛出后，后续代码（哪怕只有一行
System.out.println）**永不执行** - 不要用
throw new Exception("xxx")这种泛化写法——掩盖真实错误类型，下游无法精准捕获 - 自定义异常必须继承
Exception（受检）或RuntimeException（非受检），否则编译报错 - 构造异常时建议带上下文数据（如 ID、参数值），但严禁包含密码、token 等敏感信息
常见陷阱：finally 里 return 会吃掉异常
这是最容易被忽略的“静默吞异常”场景：当 try 中抛出异常，但 finally 块里有 return，JVM 会直接返回 finally 的值，并丢弃原始异常——调用者完全收不到报错，调试时一头雾水。
立即学习“Java免费学习笔记（深入）”；
public static int riskyMethod() {
try {
throw new RuntimeException("原始异常");
} finally {
return 42; // ❌ 这行让上面的 RuntimeException 彻底消失
}
}
- 永远不要在
finally中写return、throw或修改返回值变量 - 如果真需要清理资源，用
try-with-resources替代手动finally关闭 - 想确保异常不被掩盖？在
finally里只做纯清理（如关闭流、解锁），不做控制流操作
