Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

Item 58: 在可恢复的情况下使用checked exceptions，在程序错误时使用runtime exceptions

Java语言提供了三种throwables：

1. checked exceptions
2. runtime exceptions
3. errors

常常有人不知道什么时候用每一种。答案可能不那么清晰，但是有些通用的准则可以作为强力参考。

使用checked 或者unchecked exception的最重要准则是这个：
当你希望调用者能够根据这个异常的指导来合理地恢复，那就使用checked exceptions.
通过抛出checked exception,你强迫调用者去在catch语句中去处理异常，或者把它向外传播。每个方法抛出的checked exceptions于是就变成了一个明确的指示：相关的情况是由于调用这个API造成的。

通过让API调用者面对一个checked exception, API设计者因此可以委托/授信调用者去从那个状态恢复。用户也可以无视这个委托，只要catch住然后忽略掉就行了，但这常常是个坏主意。

有两种unchecked throwables: runtime exceptions和errors.他们在行为上是类似的：都是不应该被也不需要被捕获(caught)的异常。如果抛出了上面两种异常，说明已经产生了不太可能逆转的错误，继续执行下去可能会带来更多的危害。如果程序没有捕获这样的异常，那么线程就会停止，同时抛出合适的错误信息。

使用runtime exeception来展示程序错误(programming errors)。大部分的运行时异常都表示存在提前违例。提前违例代表API调用者没有遵循API使用明细。比如，使用数组的时候会有明细告诉你index应该在0到数组长度减一之间，那么ArrayIndexOutOfBoundsException发生了就表明你没有遵循，导致产生了提前违例(precondition violations)。

虽然JLS没有明确要求，但是错误常常被用来指示资源不足等等不能继续执行的条件。这些都是惯例了，所以最好不要再实现新的Error的子类了。所以，你实现的所有uncekced throwables都应该直接或间接地继承RuntimeException.

你也可以自定义一个不继承自Exception/RuntimeException/Error的异常。但是，不要这么做。

---

后面讲了好长的没用的话，不译了。