Runtime Exception vs Exception

在java的异常类体系中,Error和RuntimeException是非检查型异常，其他的都是检查型异常。

所有方法都可以在不声明throws的情况下抛出RuntimeException及其子类

不可以在不声明的情况下抛出非RuntimeException

简单的说，非RuntimeException要自己写catch块处理掉。或者throw

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，那么系统最终会崩溃。

Runtime Exception：

在定义方法时不需要声明会抛出runtime exception； 在调用这个方法时不需要捕获这个runtime exception； runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。 例如：nullpointexception，IndexOutOfBoundsException就属于runtime
exception

Exception:

定义方法时必须声明所有可能会抛出的exception； 在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去；exception是从java.lang.Exception类衍生出来的。例如：IOException，SQLException就属于Exception