当我们通过扩展 Exception 类创建CustomException 时，编译器会对其进行检查，但即使 RuntimeExceptions 扩展了 Exception 类，编译器也不会对其进行检查。
这是如何在编译器中建立的。我在JLS中找到了一个部分说明原因。
为什么不检查
运行时异常 运行时异常类（RuntimeException 及其子类）免于编译时检查，因为根据 Java 编程语言设计者的判断，必须声明此类异常不会显着帮助确定正确性的节目。Java 编程语言的许多操作和构造都可能导致运行时异常。编译器可用的信息以及编译器执行的分析级别通常不足以确定不会发生此类运行时异常，即使这对程序员来说可能是显而易见的。要求声明这样的异常类只会让程序员感到恼火。
在标记接口的情况下，幕后是否发生了一些事情。
我正在寻找一些可以解释它是如何完成的以及为什么所有检查的异常都没有父类的来源？
在标记接口的情况下，幕后是否发生了一些事情。
RuntimeException免除所有子类都是检查异常的规则的事实Exception只是规范的一部分。
如何实现该规则的例外取决于编译器。
编译器检查除 Error 和 RuntimeException 子类之外的所有 Throwable 子类。它只是检查 Throwable 是否是这些类的子类。
注意：你可以有一个 Throwable 的子类，它不是错误或异常，它将被检查。
在任何时候，有人可以在您的程序中输入零。如果你曾经除过，这可能会导致除以零错误，这将抛出一个RuntimeExcpetion被调用的ArithmeticException.
现在，如果您需要在所有除法语句周围包含 try / catch 块，则代码将被错误处理弄乱，这会降低代码主要目的的可读性，这可能是任何东西（但可能与捕获无关）除以零错误）。
Java 要么选择在可读性和健壮性之间取得平衡，要么在所有情况下允许健壮性，并带有一些增强可读性的“假设”。换句话说，当 Java 语言被布局时，平衡可读性和健壮性的决定看起来就像是在污染用户编写的源代码和需要ArithmeticExcpetion围绕任何除法运算捕获 s 之间的决定。另一种方法是始终确保健壮性，但使某些类型的Exceptions 不受要求的捕获，确保程序健壮性而不影响源代码的可读性（代价是知道该语言稍微复杂一些，因为它有两个类别Exceptions) 。