《Effective Java》——异常

只针对异常情况才使用异常

异常设计的初衷就是针对程序的不正常情形所使用的，不要使用异常来控制程序的执行流程

对可恢复的情况使用受检异常，对编程错误使用非受检异常

Java设计了三种可以抛出的结构

checked exception

runtim exception

error

error一般情况下，约定俗称有虚拟机使用，表示资源不足等错误

对可恢复的情况使用受检异常，对编程错误使用非受检异常

避免不必要的使用checked exception

使用checked exception会给客户端程序员带来很大的负担，只有满足如下两个条件，才应该使用checked exception

即使正确调用该api此种情况也可能发生

对于异常的发生，程序员可以立即采取有用的动作

否则，应该使用runtime exception

优先使用标准的异常

重用现有的异常，有三个好处

使你的api易于学习和使用

对于使用api的程序来说，可读性会更好

异常类越少，装载时的开销也越小

常用的异常有如下几个

IllegalArgumentException

IllegalStateException

NullPointerException

IndexOutOfBoundException

ConcurrentModificationException

UnsupportedOperationException

抛出与抽象相对应的异常

当方法要传递底层实现抛出的异常时，要进行异常转译，不要使底层实现的异常污染了上层api

例如

catch(IOException e){
throw new ServiceException(e);
}

通常有两种转译方式，一种是直接异常的转译，一种是异常链的转译

上面的例子就是异常链的转译，调用方可以通过异常获得更底层的异常，方便排查问题，直接转译就是不传递异常链，例如

catch(IOException e){
throw new ServiceException("io exception");
}

以上只是针对一定要传递底层异常情况下的处理方法，对于底层的方法，首选方案是处理掉底层异常，不将异常的影响传递到上层去，一般有两条途径来实现

对参数进行检查，避免调用底层方法发现异常

绕开异常，将异常记录下来，不传播出去

每个方法抛出的异常都要有文档

为checked exception和unchecked exception都建立文档说明，但是不要在方法声明中标记unchecked exception

在细节消息中包含能捕获失败的信息

要记录下产生该异常的各种原因，最好能使异常自身记录下产生问题的原因，例如在异常的构造函数中包含一些特别的字段，就像在IndexOutOfBoundsException中可以有如下构造方法

public IndexOutOfBoundsException(int lowerBound, int upperBound, int index){
...

努力使失败保持原子性

失败的方法调用应该使对象保持在被调用之前的状态，有几种途径可以实现这个目的

使用不可变对象

在改变状态之前检查参数有效性，提前抛出异常

将可能失败的操作放在改变状态之前执行，这样失败是可以提前结束，不至于使对象处于不一致的状态

写恢复代码（不常用），一般是对于已经持久化的数据

使操作在一个临时拷贝上执行

有时，并不总能实现失败的原子性，例如两个线程不安全的并发修改对象的状态

规范上来讲，任何调用失败都应该使对应状态位于之前的状态，如何有不一致，应该在文档中描述出来

不要忽略异常

对于异常，除了关闭InputStream时，其他时候都不要忽略异常

对异常

要么处理

要么传播出去

此建议对于checked 和unchecked异常都使用