ArrayIndexOutOfBoundsException 是一个运行时异常(因为它是java.lang.RuntimeException 的孩子),因此理论上它可以在任何地方抛出。任何代码都可以抛出所有运行时异常,而包含方法不需要在throws 子句中声明它;所以编译器不会尝试检查任何给定的代码块是否真的会抛出这样的异常。无论如何,这在任何不平凡的情况下都是不可能的;任何在非最终类上包含至少一个方法调用的代码可能抛出这样的异常(即使您当前的类都没有这样做,也可以在运行时使用不同的子类) .
另一方面,IOException 是一个检查异常,因此只能由在其 throws 子句*中显式声明它的方法抛出。
请参阅this Sun article 了解有关已检查与未检查异常的更多理念。请注意,这有点像一场宗教战争,人们推动所有例外都是双方的一个或另一个。
编辑:澄清一下,在您的第一个示例中,编译器可以可能会验证 AIOOBE 永远不会真正被抛出。但事实并非如此;首先是因为它只能在这种简单的情况下(比如这个)这样做,它不会带来任何真正的好处;其次,如果有时允许包含“不可能的”运行时异常但有时不允许包含可能会更加混乱,例如:
// Preparation stuff
private void myNoop() {}
public void publicNoop() {}
public final void finalNoop() {}
// hypothetically illegal (same as your first example)
try {
// do nothing
} catch (ArrayIndexOutOfBoundsException e) {}
// hypothetically illegal (myNoop() can't be overridden)
try {
myNoop();
} catch (ArrayIndexOutOfBoundsException e) {}
// hypothetically illegal (finalNoop() can't be overridden)
try {
finalNoop();
} catch (ArrayIndexOutOfBoundsException e) {}
// legal (publicNoop() could do anything at runtime)
try {
publicNoop();
} catch (ArrayIndexOutOfBoundsException e) {}
在我看来,改变方法(或者实际上是一个类)的访问级别或终结性会突然改变捕获某些运行时异常的合法性,这对我来说似乎很奇怪。尤其是当您考虑到 catch 块在堆栈上可能比正在更改的方法高几级时...
此外,拥有一个永远不会被调用的 catch 块是无害的,真的。 “如果出现 AIOOBE,这就是你如何处理它”——而且它永远不会在运行时发生。受检查的异常实际上也可能发生同样的情况。例如,Callable.call() 被声明为抛出 Exception,但您使用的特定实现可能永远不会抛出任何异常 - 所以同样,您将获得有关如何处理永远不会在运行时调用的异常的说明。
在一天结束的时候,编译器只是指出了差异——“你确定你打算捕获 IOException,因为这段代码永远不会运行吗?”它就像静态类型,因为它会自动提醒您界面的变化。存在运行时异常,因此您不必声明每个方法都可以抛出 NullPointerException 等。
*从技术上讲,这并不完全正确,这有一些低级漏洞,但从广义上讲,情况确实如此。例外情况通常是异常、伪影和/或已弃用。