Java自定义异常，应该继承Exception还是Runtime Exception，为什么？

Exception分为编译时异常和运行时异常，编译时异常也叫做checkedException,运行时异常也叫做uncheckedException
什么是检查型异常（Checked Exception）与非检查型异常（Unchecked Exception）？
https://www.cnblogs.com/tjudzj/p/7053980.html

如果抛出Exception，比如throw new Exception(“error message”);则必须要对该异常进行处理，要么自己try catch,要么使用throws语句在方法上抛出给调用者，让调用者去处理，而且调用者必须处理，否则编译不会通过，这样的好处是出现该异常时由于调用方处理了，所以程序不会停止运行，缺点是耦合性太高了，如果不throws抛出，那么代码中会有大量的try catch
如果抛出的是Runtime Exception，则不需要处理，但是一旦出现该异常，程序会停止运行，优点是代码简洁
总结：如果这个异常发生，用户自己能够有法解决，那就用checked exception。RuntimeException直白讲就是系统异常，或者系统出错了。或程序有Bug，或环境有问题。比如空指针，SQL语法错误，数据库连不上，用户对这些异常是无能为力的，碰到这类异常系统统一处理-就告诉用户:系统出现异常了
1、Exception： 非运行时异常，在项目运行之前必须处理掉。一般由程序员try catch掉 或者 throws抛出。
2、RuntimeException，运行时异常，在项目运行之后出错则直接中止运行，异常由JVM虚拟机处理。

网上摘得一段话，比喻的很恰当：
　　继承Exception还是继承RuntimeException是由异常本身的特点决定的，而不是由是否是自定义的异常决定的。
　　例如我要写一个java api，这个api中会调用一个极其操蛋的远端服务，这个远端服务经常超时和不可用。所以我决定以抛出自定义异常的形式向所有调用这个api的开发人员周知这一操蛋的现实，让他们在调用这个api时务必考虑到远端服务不可用时应该执行的补偿逻辑（比如尝试调用另一个api）。此时自定义的异常类就应继承Exception，这样其他开发人员在调用这个api时就会收到编译器大大的红色报错：【你没处理这个异常！】，强迫他们处理。
　　又如，我要写另一个api，这个api会访问一个非常非常稳定的远端服务，除非有人把远端服务的机房炸了，否则这个服务不会出现不可用的情况。而且即便万一这种情况发生了，api的调用者除了记录和提示错误之外也没有别的事情好做。但出于某种不可描述的蛋疼原因，我还是决定要定义一个异常对象描述“机房被炸”这一情况，那么此时定义的异常类就应继承RuntimeException，因为我的api的调用者们没必要了解这一细微的细节，把这一异常交给统一的异常处理层去处理就好了。
　　总结一下：
　　抛出 RuntimeException（运行期才可以发现的异常），调用方法的程序员不需要知道会出这个异常。
　　抛出Exception的方法，调用者需要明确知道这个方法里会出现什么异常，并提示调用者要去处理这个可能得异常。
　　简单的说，非RuntimeException必要自己写catch块处理掉。RuntimeException不用try catch捕捉将会导致程序运行中断，若用则不会中断。