RuntimeExceptions如何不被编译器检查，即使它们扩展了Exception类？

Question

当我们通过扩展Exception类创建 CustomException时，它会被编译器检查，但即使RuntimeExceptions扩展Exception类，它们也不会被编译器检查。

这是如何在编译器中建立的。我在JLS中找到了一个说明原因的部分。

  

为什么不检查运行时异常
  运行时异常类（RuntimeException及其子类）免于编译时检查，因为在Java编程语言的设计者的判断中，必须声明此类异常不会有助于建立程序的正确性。 Java编程语言的许多操作和构造都可能导致运行时异常。编译器可用的信息以及编译器执行的分析级别通常不足以确定不会发生此类运行时异常，即使这对程序员来说可能是显而易见的。要求声明这样的异常类只会让程序员感到恼火。

幕后是否会发生某些事情，例如标记界面。

我正在寻找一些可以解释它是如何完成的来源以及为什么没有所有已检查异常的父类？

Answer 1

  

幕后会发生什么事情，例如标记界面。

RuntimeException被免除Exception的所有子类都被检查的例外规则的事实只是规范的一部分。

如何实现规则的此异常取决于编译器。

Answer 2

编译器检查除Error和RuntimeException的子类之外的所有Throwable子类。它只是检查Throwable是否是这些类的子类。

注意：您可以拥有一个Throwable的子类，它不是错误或异常，它将被检查。

Answer 3

在任何时候，有人可以在你的程序中输入零。如果你划分，那么可能会导致除以零的错误，这将导致RuntimeExcpetion被称为ArithmeticException。

现在，如果你需要在所有的除法语句中包含try / catch块，那么代码就会混乱，错误处理会降低代码主要用途的可读性，这可能是任何东西（但可能是不是'关于捕捉零除错误。）

Java可以选择在可读性和健壮性之间取得平衡，或者在所有情况下都允许使用一些增强可读性的“假设”。换句话说，当Java语言被布局时，平衡可读性和稳健性的决定看起来像是在污染用户编写的源代码与需要捕获围绕任何除法操作的ArithmeticExcpetion之间的决定。另一种方法是始终确保稳健性，但使某些类型的Exception不受所需捕获的影响，确保程序的健壮性，而不会影响源代码的可读性（代价是知道语言稍微复杂一些）因为它有两类Exception s）。