Effective Java 2 读书笔记 第9章 异常
第57条:只针对异常的情况才使用异常
- 异常应该只用于异常的情况下,不该用于正常的控制流
// Horrible abuse of exceptions. Don't ever do this! try { int i = 0; while(true) range[i++].climb(); } catch(ArrayIndexOutOfBoundsException e) { }
- 设计良好的API不应该强迫它的客户端为了正常的控制流而使用异常,可以提供状态测试(hashNext())或者可识别的返回值(return null)。
第58条:对可恢复的情况使用受检异常,对编程错误使用运行时异常
java有三种可抛出的结构(throwable),受检的异常(checked exception)、运行时异常(run-time exception)和错误(error)。
- 如果期望调用者能够适当地恢复,对于这种情况就应该使用受检的异常。或者在catch中处理,或者传播出去,如sql,io Exception。这样的异常可以提供辅助方法,使得调用者得到一些有助于恢复的信息。
- 用运行时异常来表明编程错误。大多数运行时异常都是前提违例(precondition violation)。就是没有遵守API规范建立的约定。如数组下标不能越界
- 情况并不是绝对的,如考虑资源枯竭的情形,可能是因为程序的错误引起的,如分配了不合理的大叔组,如果资源是因为临时的短缺或者临时需求太大所造成的,这种情况可能就是可恢复的。API设计者需要判断这样的资源是否允许回复。如果你相信一种情况可能允许恢复,那么使用受检异常,否则使用运行时异常。不清楚,最好使用未受检的异常。
第59条:避免不必要第使用受检的异常
如果正确地使用API并不能阻止这种异常条件的产生,并且一旦产生异常,使用API的程序员可以立即采取有用的动作,这种负担就被认为是正当的。除非这两个条件都成立,否则更适合于使用未受检的异常。
理解不深刻
第60条:优先使用标准的异常
追求重用,异常也不例外。
- 重用异常的好处:
- 使你的API更加易于学习和使用,因为它与程序员已经熟悉的习惯用法是一致的
- 可读性更好
- 异常类越少,内存印迹就越小,装载这些类的时间开销也越小
- 常用异常
- 选择重用哪个异常并不总是那么精确,使用场合不排斥。
第61条:抛出与抽象相对应的异常
- 更高层的实现应该捕获低层的异常,同时抛出可以按照高层抽象进行解释的异常,即异常转译(Exception translation)
// Exception Translation try { // Use lower-level abstraction to do our bidding ... } catch(LowerLevelException e) { throw new HigherLevelException(...); }
- 异常链,低层的异常对于调试导致高层异常的问题有帮助的时候使用
// Exception Chaining try { ... // Use lower-level abstraction to do our bidding } catch (LowerLevelException cause) { throw new HigherLevelException(cause); }
- 尽管异常转译与不加选择第从底层传递异常的做法相比有所改进,但是它也不恩那个被滥用。如果可能,处理来自低层异常的最好做法是,在调用低层方法之前确保它们会成功执行,从而避免它们抛出异常。如在给低层传递参数之前,检查高层参数有效性,从而避免低层抛出异常
- 如果无法避免低层异常,次选是,让更高层来悄悄绕开这些异常,从而将高层方法的调用者与低层的问题隔离开来。如使用java.util.logging将异常记录下来。
第62条:每个方法抛出的异常都要有文档
- 始终要单独地声明受检的异常,并且利用[email protected]标记,准确第记录下抛出每个异常的条件,如果一个方法可能抛出多个异常类,则不要使用“快捷方式”声明它会抛出这些异常类的某个超类。永远不要声明一个方法“throws Exception“,或者更糟的是声明”throws Throwable",这是非常极端的例子。这样的声明不仅没有指导信息,反而妨碍使用,因为它掩盖了该方法可能抛出的任何其他任何异常。
- 使用Javadoc的@throws标签记录下一个方法可能抛出的每个未受检异常,但是不要使用throws关键字将未受检的异常包含在方法的声明中。
- 使用API的程序员必须知道哪些异常是需要受检的,那么是不需要受检的,这很重要,因为这两种情况下他们的责任不同。
- 注意:类被修订之后,可能会出现新的异常,尽管以前并没有声明这些异常
- 如果一个类中的许多方法出于同样的原因而抛出同一个异常,在该类的文档注释中对这个异常建立文档,这是可以接受的。
总之,要为每个方法所能抛出的每个异常建立文档。要为每个受检异常提供单独的throws子句。不要为未受检的异常提供throws子句。
第63条:在细节消息中包含能捕获失败的消息
为了捕获失败,异常的细节信息应该饱和所有“对该异常有贡献”的参数或者域的值,虽然java平台类库没有广泛这么做,但是值得大力推荐,它使得程序员更加易于抛出异常以捕获失败。
第64条:努力使失败保持原子性
一般而言,失败的方法调用应该使对象保持在被调用之前的状态。具有这种熟悉的方法被成为具有失败原子性(failure atomic)。
- 最简单的办法莫过于设计一个不可变的对象,如果对象不可变,失败原子性就是显然的了
- 对于在可变对象上执行操作的方法,获得原子性最常见的办法是,在执行操作之前检查参数的有效性。如
public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; // Eliminate obsolete reference return result; }
- 做恢复代码,回滚
- 在对象的临时拷贝上进行操作,完成之后在用临时拷贝中的结构代替对象的内容。
一般而言,作为方法规范的一部分,产生任何异常都应该让对象保持在该方法调用之前的状态。如果违反这条规则,API文档就应该清楚地指明对象将会处于什么样的状态。
第65条:不要忽略异常
- 当api的设计者声明一个方法将抛出某个异常的时候,他们等于正在试图说明某些事情,因此不要忽略它。
- 空的catch会时异常达不到应有的目的,至少,catch块也应该保护一条说明,解释为什么可以忽略这个异常