方法重写与异常处理：运行时多态中编译器的作用及规则理解确认

核心判断：你的推导逻辑完全正确 #

你对规则成因的推导完全命中了Java异常重写约束的设计本质，没有认知偏差。整个规则的设计出发点，就是为了适配多态场景下“编译期类型检查、运行期动态绑定”的双层执行逻辑，避免出现编译通过但运行时异常漏捕获的问题。

规则设计要规避的核心问题 #

我们可以把你假设的“允许子类声明更宽泛异常”的场景完整走一遍，就能直观看到问题：

// 父类定义的公开方法契约
class Parent {
  public void disp() throws IOException {
    System.out.println("Parent disp()");
  }
}

// 假设放开限制，允许子类在重写时放宽异常范围
class Child extends Parent {
  public void disp() throws Exception { // 声明比父类更宽泛的Exception
    System.out.println("Child disp()");
  }
}

当调用方用多态方式发起调用时：

Parent p = new Child();

此时编译器做异常合规检查的依据，永远是代码里的引用类型对应的方法签名，也就是Parent类的disp()方法。它只会提示开发者：这个方法会抛出IOException，只要按照这个声明做异常处理，代码就可以正常编译通过，参考写法：

try {
  p.disp();
} catch (IOException e) {
  // 按照编译器要求写的处理逻辑
}

此时核心矛盾就出现了：Java的异常捕获规则是，catch块只会匹配对应异常类型及其所有子类型，无法捕获该类型的超类异常。上面代码里的catch(IOException e)只能捕获IOException本身和它的所有子类，运行时实际执行Child类的重写方法时，如果抛出了属于Exception范畴但不属于IOException的异常（比如SQLException），这个catch块根本没有能力兜住，最终会导致未处理的异常直接击穿程序执行流程。这类问题在编译阶段完全无法被发现，会直接破坏Java受检异常“编译期强制覆盖所有可预期异常”的核心设计目标。

规则的正向设计逻辑 #

正是为了规避这类问题，Java才强制要求：

• 子类重写的方法，不能声明比父类方法更宽泛的受检异常
• 可以声明和父类完全相同的受检异常
• 可以声明父类异常的子类（范围更窄的异常类型），甚至可以完全不声明任何受检异常

这种约束本质是保证：不管运行时实际绑定的是哪个子类的实例，它抛出的所有受检异常，一定全部落在父类方法签名声明的异常范围内。调用方按照父类方法的契约写的异常处理逻辑，永远可以兜住所有实际运行时抛出的受检异常，不会出现漏捕获的问题。

你提出的两个推导结论的准确性验证 #

• 关于编译期行为的结论完全正确：编译器在做方法匹配、重写规则校验、异常合规检查的时候，只会根据代码里的引用类型查找对应的方法签名，根本不会提前感知这个引用实际指向的子类实例。这也是所有重写规则的核心设计依据——所有重写行为都必须保证子类的方法，完全兼容父类引用能使用的方法契约。
• 关于运行期行为的结论完全正确：JVM在实际执行方法调用时，会根据实例的实际类型找到最匹配的重写方法执行，这也是Java多态特性的核心实现机制。

内容的提问来源于stack exchange，提问作者Syed Zabi Ulla