转载

Effective Java 3rd Edition — 第十章异常

Item 69 : Use exceptions only for exceptional conditions

只在异常情况下使用异常

// Horrible abuse of exceptions. Don't ever do this! 
try {    
    int i = 0;    
    while(true)        
    range[i++].climb(); 
} catch (ArrayIndexOutOfBoundsException e) {}

上面错误的使用了异常，在循环中使用ArrayIndexOutOfBoundsException只是为了保证没有越界发生，这种情况应该是使用增强的for循环来避免

for (Mountain m : range)    m.climb();

异常只是设计用在一些异常的场景，而不是通过异常来作一些性能提升；同时把代码放在try-catch代码块中会影响jvm的某些优化；通常数组的循环不需要额外的冗余检查，jvm会自动优化。

异常检查的场景通常会影响性能，并且也不一定能够保证代码正常执行，如果在循环中调用了一个方法抛出了数组越界，但是该方法在try-catch块中，这对定位bug增加了不少难度，但是如果没有这样程序则会直接抛出异常并终止运行。

总的来说就是异常只用在需要异常检查的场景，而不是用于普通的流程控制。同时在API中，好的API不会强迫用户在普通流程控制中使用异常。

一个状态依赖的类，如果在不可预测的条件下执行则需要提供一个状态检查的方法来判断是否可执行，比如迭代器的hasNext方法或者也可以返回一个不同的值，比如null来表示无法进行操作。

如果没有外部同步的情况下访问对象或者状态会受到外部影响则应该使用后者，除此之外应使用状态检查方法，状态检测方法拥有更好的可读性，并且能更容易检查到错误使用：如果没有调用状态检测方法则会抛出异常但后者如果你忘了对返回值进行检查的话就可能引起严重的错误。

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

在需要恢复的场景使用检查异常，程序错误使用运行时异常

Java提供了3种可抛出异常：检查异常、运行时异常、错误

在可以合理预期调用者恢复的情况下使用检查异常，抛出检查异常将强迫调用者去处理该异常或者继续向外抛出。未检查异常包括运行时异常和错误，这两种异常通常都不应该被捕获，抛出未检查异常表明基本不可能被恢复并且如果继续执行将会更糟。

使用运行时异常来表明程序错误，大多数的运行时异常都表示违反了前提条件，比如数组的下标都是非负数。而错误则只是JVM用来表明资源不足，持续性的失败或者其他任何导致程序继续执行的情况。通常情况下都不要继承任何Error类，而你的未检查异常则应该是RuntimeException的子类（直接或间接）。

总的来说检查异常是用于可恢复的场景，而未检查异常则用于程序错误，不知道用什么的时候使用后者。同时不要定义任何既不是检查异常也不是运行时异常的 Throwables 。

Item 71: Avoid unnecessary use of checked exceptions

避免使用不必要的检查异常

API中过度的使用检查异常会增加使用API的负担，调用者需要反复的编写try-catch代码块来处理异常，这在Java8中更加的明显，因为在流中不能使用抛出检查异常的方法。

这个时候可以返回不同的值以便在流中可以使用，或者把检查异常改为未检查异常。

总的来说适当的使用检查异常可以增加程序的稳定性，但是滥用则会导致使用十分麻烦，如果调用者不能从失败中恢复，则抛出未检查异常更为合适，只有在失败失败情况下信息不足时才抛出检查异常。

Item 72: Favor the use of standard exceptions

使用标准异常

复用标准异常有几个好处：

会使你的API更加的容易上手，因为使用的标准异常都熟悉；
使用API的代码更容易阅读，因为没有不熟悉的异常类；
更少的异常类意味着更少的内存占用和类加载时间；

可以说每个错误的方法调用都可以归结于非法的参数或状态，其他例外异常都用于某些类型的非法参数和状态。比如传入一个null值，调用则会抛出 NullPointerException 异常而不是 IllegalArgumentException 。

IllegalArgumentException 用于调用者的参数不正确；

IllegalStateException 表示接收的对象状态不合法，比如调用者想要在对象初始化前使用该对象；

ConcurrentModificationException 用于如果一个设计在单线程场景的对象检测到被修改了抛出该异常，但是该异常充其量只是一个提示，并不能可靠的检测并发修改。

不要直接使用 Exception RuntimeException Throwable Error ，把他们当成抽象类。

Item 73: Throw exceptions appropriate to the abstraction

抛出适合抽象的异常

高级封装的API应该catch掉同层级的低等级异常，同时用高级封装来抛出异常，这通常叫做异常转换

比如 AbstractSequentialList

/**
 * Returns the element at the specified position in this list.
 *
 * 

This implementation first gets a list iterator pointing to the
 * indexed element (with <tt>listIterator(index)</tt>).  Then, it gets
 * the element using <tt>ListIterator.next</tt> and returns it.
 *
 * @throws IndexOutOfBoundsException {@inheritDoc}
 */
public E get(int index) {
    try {
        return listIterator(index).next();
    } catch (NoSuchElementException exc) {
        throw new IndexOutOfBoundsException("Index: "+index);
    }
}

异常链：低级异常通过高级异常的封装抛出，同时高级封装包含了低级封装的异常信息有助于debug。

虽然异常转换优于低层异常的抛出，但是也不能过度使用，最好就是处理掉低层的异常。如果无法避免低层异常的抛出，则高层最好静默处理掉这些异常，让上层调用者没有感知，这样有可能让一些日志组件无法记录异常信息。

总的来说避免底层的异常时不太可行的，通过异常转换来处理低层的异常来隔离用户，或者使用异常链来抛出合适的异常。