第58条：对可恢复的情况使用受检异常，对编程错误使用运行时异常

Java程序设计语言提供了三种可抛出结构：受检的异常、运行时异常和错误。
在决定使用受检的异常或是或受检的异常时，主要的原则是：如果期望调用者能够适当恢复，对于这种情况就应该使用受检的异常。通过抛出受检的异常，强迫调用者在一个catch字句中处理该异常，或者将它传播除去。因此，方法中声明要抛出的每个受检的异常，都是对API用户的一种潜在指示：与异常相关联的条件是调用这个方法的一种可能的结果。
API设计者让API用户面对受检的异常，以此强制用户从这个异常条件中恢复。
有两种未受检的可抛出结构：运行时异常和错误。在行为上两者是等同的：它们都不需要也不应该被捕获的可抛出结构。如果程序抛出未受检的异常或者错误，往往就属于不可恢复的情形，继续执行下去有害无益。如果程序没有捕捉到这样的可抛出结构，将会导致当前线程停止，并出现适当的错误消息。
用运行时异常来表明编程错误。大多数的运行时异常都表示前提违例。所谓前提违例是指API的客户没有遵守API规范建立的约定。例如数组访问越界。
按照惯例，错误往往被JVM保留用于表示资源不足、约束失败，或者其他使程序无法继续执行的条件。所以最好不要再实现任何新的Error子类。因此你实现的所有未受检的抛出结构都应该是RuntimeException的子类（直接的或者间接的）。
总而言之，对于可恢复的情况，使用受检的异常；对于程序错误，则使用运行时异常。有时候并不是那么的黑白分明，如果你相信有一种情况可能允许恢复，就使用受检异常。如果不清楚是否能恢复，就使用未受检的异常。