Effective Java 2 读书笔记 第9章 异常

第57条：只针对异常的情况才使用异常

1. 异常应该只用于异常的情况下，不该用于正常的控制流

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

    
2. 设计良好的API不应该强迫它的客户端为了正常的控制流而使用异常，可以提供状态测试（hashNext()）或者可识别的返回值(return null)。

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

java有三种可抛出的结构（throwable），受检的异常（checked exception）、运行时异常（run-time exception）和错误（error）。

1. 如果期望调用者能够适当地恢复，对于这种情况就应该使用受检的异常。或者在catch中处理，或者传播出去，如sql，io Exception。这样的异常可以提供辅助方法，使得调用者得到一些有助于恢复的信息。
   
2. 用运行时异常来表明编程错误。大多数运行时异常都是前提违例（precondition violation）。就是没有遵守API规范建立的约定。如数组下标不能越界
3. 情况并不是绝对的，如考虑资源枯竭的情形，可能是因为程序的错误引起的，如分配了不合理的大叔组，如果资源是因为临时的短缺或者临时需求太大所造成的，这种情况可能就是可恢复的。API设计者需要判断这样的资源是否允许回复。如果你相信一种情况可能允许恢复，那么使用受检异常，否则使用运行时异常。不清楚，最好使用未受检的异常。

第59条：避免不必要第使用受检的异常

如果正确地使用API并不能阻止这种异常条件的产生，并且一旦产生异常，使用API的程序员可以立即采取有用的动作，这种负担就被认为是正当的。除非这两个条件都成立，否则更适合于使用未受检的异常。

理解不深刻

第60条：优先使用标准的异常

追求重用，异常也不例外。

1. 重用异常的好处：
   1. 使你的API更加易于学习和使用，因为它与程序员已经熟悉的习惯用法是一致的
   2. 可读性更好
   3. 异常类越少，内存印迹就越小，装载这些类的时间开销也越小
2. 常用异常

   

3. 选择重用哪个异常并不总是那么精确，使用场合不排斥。

第61条：抛出与抽象相对应的异常

1. 更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常，即异常转译（Exception translation）

   // Exception Translation
   
   
   try {
   
   
   // Use lower-level abstraction to do our bidding
   
   
   ...
   
   
   } catch(LowerLevelException e) {
   
   
   throw new HigherLevelException(...);
   
   
   }

    
2. 异常链，低层的异常对于调试导致高层异常的问题有帮助的时候使用

   // Exception Chaining
   
   
   try {
   
   
   ... // Use lower-level abstraction to do our bidding
   
   
   } catch (LowerLevelException cause) {
   
   
   throw new HigherLevelException(cause);
   
   
   }

    
   
3. 尽管异常转译与不加选择第从底层传递异常的做法相比有所改进，但是它也不恩那个被滥用。如果可能，处理来自低层异常的最好做法是，在调用低层方法之前确保它们会成功执行，从而避免它们抛出异常。如在给低层传递参数之前，检查高层参数有效性，从而避免低层抛出异常
4. 如果无法避免低层异常，次选是，让更高层来悄悄绕开这些异常，从而将高层方法的调用者与低层的问题隔离开来。如使用java.util.logging将异常记录下来。
   

第62条：每个方法抛出的异常都要有文档

1. 始终要单独地声明受检的异常，并且利用Javadoc@throws标记，准确第记录下抛出每个异常的条件，如果一个方法可能抛出多个异常类，则不要使用“快捷方式”声明它会抛出这些异常类的某个超类。永远不要声明一个方法“throws Exception“，或者更糟的是声明”throws Throwable"，这是非常极端的例子。这样的声明不仅没有指导信息，反而妨碍使用，因为它掩盖了该方法可能抛出的任何其他任何异常。
2. 使用Javadoc的@throws标签记录下一个方法可能抛出的每个未受检异常，但是不要使用throws关键字将未受检的异常包含在方法的声明中。
3. 使用API的程序员必须知道哪些异常是需要受检的，那么是不需要受检的，这很重要，因为这两种情况下他们的责任不同。
4. 注意：类被修订之后，可能会出现新的异常，尽管以前并没有声明这些异常
5. 如果一个类中的许多方法出于同样的原因而抛出同一个异常，在该类的文档注释中对这个异常建立文档，这是可以接受的。

总之，要为每个方法所能抛出的每个异常建立文档。要为每个受检异常提供单独的throws子句。不要为未受检的异常提供throws子句。

第63条：在细节消息中包含能捕获失败的消息

为了捕获失败，异常的细节信息应该饱和所有“对该异常有贡献”的参数或者域的值，虽然java平台类库没有广泛这么做，但是值得大力推荐，它使得程序员更加易于抛出异常以捕获失败。

第64条：努力使失败保持原子性

一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种熟悉的方法被成为具有失败原子性（failure atomic）。

1. 最简单的办法莫过于设计一个不可变的对象，如果对象不可变，失败原子性就是显然的了
2. 对于在可变对象上执行操作的方法，获得原子性最常见的办法是，在执行操作之前检查参数的有效性。如
   

   public Object pop() {
   if (size == 0)
   throw new EmptyStackException();
   Object result = elements[--size];
   elements[size] = null; // Eliminate obsolete reference
   return result;
   }

    
   
3. 做恢复代码，回滚
4. 在对象的临时拷贝上进行操作，完成之后在用临时拷贝中的结构代替对象的内容。

一般而言，作为方法规范的一部分，产生任何异常都应该让对象保持在该方法调用之前的状态。如果违反这条规则，API文档就应该清楚地指明对象将会处于什么样的状态。

第65条：不要忽略异常

1. 当api的设计者声明一个方法将抛出某个异常的时候，他们等于正在试图说明某些事情，因此不要忽略它。
   
2. 空的catch会时异常达不到应有的目的，至少，catch块也应该保护一条说明，解释为什么可以忽略这个异常