Exception和继承自Exception的RuntimeException区别

Java compiler要求所有的Exception 要么被catch,要么被throw，除非这是一个RuntimeExeption (e instanceof RuntimeException)。也就是说，通常的Exception一定要被处理，也即我们所说的 checked exception，而RuntimeException不强制要求处理，（当然你自己要处理也可以），所以我们称为unchecked exception。 
之所以区分 checked/unchecked exception，JAVA的设计思想是区分从类/方法设计者角度来看两种不同的异常： 
一种是设计者认为这个方法在使用过程中使用者能够处理的异常，这些往往作为checked exception。比如一个IO系统的设计者会认为诸如物理文件不存在或者介质无法读取等异常时很可能发生，而使用者完全可能捕获这个异常，通过让用户重新输入文件名等方式重新进行这个操作，也就是说，这是一个可恢复的操作。所以我会在诸如 read()/write()等操作中throw 一个 IOException(checked exception)。 
第二种是设计者认为使用者不能够处理的异常，比如我写一个函数要求传入的参数是个正数，那么当我发现使用者传了个负数进来时，合理的预期是程序中出bug了。如果我抛出一个异常描述这件事，即使我要求调用者捕获这个异常，他肯定也不知道该怎么办(总不能随便传一个正数进来吧）。这时候我就会抛出一个IllegalArgumentException(uncheck exception)，这里面的潜台词是：小子，我知道你也是帮人背黑锅的，处理不了这个，你还是交给你的领导（调用你的程序）去处理这个异常吧。 
同理，当JVM发现除数为0时，抛出的ArithmeticException也是一个unchecked exception。 

从这里可以看出，checked exception和 unchecked exception的根本区别在于设计者认为使用者是否能够并且应该处理这个异常。不幸的是，由于Java使用者水平的参差不齐，大量的unchecked exception该被设计成了checked exception，而对于真正的checked exception，又有太多被catch了之后啥都不作就悄无声息了。尤其是不声不响吞噬exception的行为，不但达不到设计者本来的要求（进行恢复处理），甚至问题更大(连 unchecked exception那种最后报错的效果都没了）。 

所以， C#在异常处理上采用了完全不同的思路，把所有的的exception都设计为 unchecked exception，也就是说，它基于这样一种思路： 我不要求任何人处理任何异常；如果你能处理，那么你就显示catch这种异常；如果某种异常没有人catch，那么系统最终会崩溃。

ps:

RuntimeException 是属于unchecked （java 编译器允许不catch）表示一类 未知的不确定的只有在运行时才会出现的异常。 
而非RuntimeException 是checked （java 编译器必须要求 catch），大概指一类可以预知的，当发生异常后知道如何处理的异常，所以需要捕获。