Java标准异常的层次结构代表的分类绝对是一个败笔。因为所有的异常对象都是在运行时抛出的，没听说过有什么编译期异常。因此RuntimeException类代表的实际上是逻辑错误导致的异常，即标准c++中的std::logical_error。
Java异常分为两大类，程序员只能抛出Exception异常对象，Error对象是Java系统在内部发生错误或者资源耗尽时才抛出的。
还有另外一种分类方法，Error和RuntimeException对象被称为unchecked exception,其他的则被称为checked exception,也就是说java编译器将对checked exception检查是否提供了异常处理器（catch子句）。如果你的方法的异常规格表明可能会抛出一个checked exception,而你却没有使用catch子句处理这个可能抛出的checked exception，编译器会报错。
当抛出异常时，如果希望调用者能够拦截并且恢复程序的执行，应该抛出checked exception（即可恢复情况使用checked exception)。为了让调用者能够恢复程序的执行,checked exception对象往往需要提供一些方法使得调用者可以获得一些有助于恢复的信息。所以，换位思考是个好主意，想一想如果调用者拦截了你抛出的异常，他能够恢复程序的执行，你就应该抛出checked exception，否则你就应该抛出RuntimeException.
对于程序错误（比如引用为空，方法的前提条件不满足等不可恢复情况）应该抛出RuntimeException。
注意，我们的方法不需要检查参数引用是否为空，Java运行时已经替我们做了。
异常对象的传递机制是从异常抛出的地方往调用链的反方向传递。如果我们catch到了一个从底层抛出的异常，我们如何处理呢。如果我们能够处理该异常，我们应该处理该异常。如果我们不能处理该异常，需要继续传递时，我们需要考虑我们调用者能否理解这个底层传递过来的异常的含义。有时候调用者并不理解底层的异常，甚至都不知道有底层这个抽象设计存在，需要我们将异常进行转换，抛出调用者能够理解的异常对象。
为方法抛出的exception编写注释
如果一个方法可能抛出checked exception和unchecked exception。你有两种做法，一是在异常规格中说明checked exception，然后在注释中使用@throws class description来说明unchecked exception。二是你决定避免使用异常规格，你就需要在@thorws说明所有的异常对象。
在方法的后面加上throws class1,class2 表示该方法肯能抛出class1或者class2对象作为checked exception。
Java的异常规格说明和c++不同的地方是：
1)Java方法的异常规格只需要说明checked exception
2)Java方法内部如果抛出了一个checked exception，而没有在异常规格中描述该异常类型，编译器会检查并报错
3)调用具备异常规格的Java方法而不提供catch子句来处理对应的异常的行为会被编译器检查并报错
4)Java方法实现者不应该在异常规格中说明unchecked exception，而应该在方法内部防止抛出RuntimeException,对于Error则无须考虑。
5)出于性能以及其他原因，C++并不建议使用异常规格，（实际上C++世界目前已经承认异常规格是一个失败的主意，详细原因可以参考我的<<C++ Summary>>文章）。目前Java世界也出现了类似的声音，主要是认为大型工程中使用异常规格声明checked exception并不合适。因为有些时候并不需要添加不必要的catch块，而只是希望异常对象能够向上传递。在这种情况下可以使用RuntimeException的构造函数将一个checked exception转换成不需说明的RuntimeException对象，就可以避免对我们的方法使用异常规格。具体例子请参考<<Thinking in Java>>4
