在没有真正了解java的异常处理体系之前，我一直认为凡是调用有throws异常的api，一定要用try捕获处理，否则编译会过不去。直到有一次我发现事情不是这样的，在了解之后，知道了凡是继承RuntimeException（运行期才可以发现的异常）的异常是不需要显式的用try捕获。但一直不知道怎么理解java为什么有这样的设计，直到有一天无意中在网上了看到了下面这段话。
以下这段话为转载，已经找不到出处了，作者请见谅。
------------------------------------我是害羞的转载分割线------------------------------------
继承Exception还是继承RuntimeException是由异常本身的特点决定的，而不是由是否是自定义的异常决定的。例如我要写一个java api，这个api中会调用一个极其操蛋的远端服务，这个远端服务经常超时和不可用。所以我决定以抛出自定义异常的形式向所有调用这个api的开发人员周知这一操蛋的现实，让他们在调用这个api时务必考虑到远端服务不可用时应该执行的补偿逻辑（比如尝试调用另一个api）。此时自定义的异常类就应继承Exception，这样其他开发人员在调用这个api时就会收到编译器大大的红色报错：【你没处理这个异常！】，强迫他们处理。又如，我要写另一个api，这个api会访问一个非常非常稳定的远端服务，除非有人把远端服务的机房炸了，否则这个服务不会出现不可用的情况。而且即便万一这种情况发生了，api的调用者除了记录和提示错误之外也没有别的事情好做。但出于某种不可描述的蛋疼原因，我还是决定要定义一个异常对象描述“机房被炸”这一情况，那么此时定义的异常类就应继承RuntimeException，因为我的api的调用者们没必要了解这一细微的细节，把这一异常交给统一的异常处理层去处理就好了。
------------------------------------我是害羞的转载分割线------------------------------------
简单地说，当你觉得封装的api中有必须要让调用方在编译期就必须处理的异常，则抛出（throws E）继承了Exception的异常。否则就抛出继承了RuntimeException的异常。调用抛出Exception异常的程序，必须用try catch来处理，否则编译无法通过。而调用抛出RuntimeException异常的程序，你不必用try catch来处理，发生错误的时候去后台查看日志好了。当然，如果你愿意用try把它处理了，也无可厚非。