Effective Java 读书笔记2

4.异常

4.1 仅在发生异常的条件下使用异常

永远不要使用异常来控制正常流程

缺点：

基于异常的循环不仅混淆了代码的目的，降低了代码的性能，而且不能保证它能正常工作
如果代码中出现bug，使用异常控制流程可能会掩盖bug

4.2 对可恢复条件使用检查异常，对编程错误使用运行时异常

如果期望调用者能够恢复，对于这样条件就应该使用被检查异常。每个受检异常都是对api用户的一种潜在提示：调用这个方法可能会出现异常，处理这个异常来恢复程序运行

运行时异常和错误一般会把当前线程停止掉，并且伴随一个错误信息出来。当然运行时异常你也可以捕获，但是一般逻辑上是没有意义的，因为运行时一般都是你代码写错了。

4.3 避免不必要地使用受检异常

受检的异常是Java程序设计语言的一项很好的特性。与返回代码不同，它们强迫程序员处理异常的条件，大大增强了可靠性。如果方法抛出一个或者多个受检的异常，调用该方法的代码就必须在一个或者多个catch块中处理这些异常，或者它必须声明它抛出这些异常，并让它们传播出去。无论哪种方法，都给程序员增添了不可忽视的负担。

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

「把受检异常变成未受检异常」的一种方法是，把这个抛出异常的方法分成两个方法，其中第一个方法返回一个 boolean 值，表明是否应该抛出异常。

//Invocation with checked exception
 
try {
 
     obj.action(args);
 
} catch(TheCheckedException e) {
 
      // Handle exceptional condition
 
}

　　重构为：

// Invocation with state-testing method and unchecked exception
 
if (obj.actionPermitted(args))  { 
 
      obj.action(args);.
 
} else {
 
       // Handle exceptional condition
 
}

4.4 优先使用标准的异常

重用现有的异常有多方面的好处

1.他使你的API更加易于学习和使用，因为他与程序员已经熟悉的习惯用法是一致的。

2.对于用到这些API的程序而言，他们的可读性会更好，因为他们不会出现很多程序员不熟悉的异常。

3.异常类越少，意味着内存印迹就越小，装载这些类的时间开销也越少。

不要直接重用Exception,RuntimeException,Throwable或者Error

4.5 抛出与抽象对应的异常

更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译

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

虽然比直接传递低层异常有所改进，但是不能滥用。最好的做法就是，尽量保证低层方法调用成功执行，避免出现异常。如果无法避免异常，则处理异常并将异常记录下来

4.6 每个方法抛出的所有异常都要建立文档

利用Javadoc的@throws标记记录异常

4.7 在细节消息中包含失败-捕获信息

为了在异常发生后捕捉失败原因，一个异常的字符串表示应该包括所有“对该异常有贡献”的参数和域的值。也就是说在异常所能“携带”的信息中，尽量多的加入对调试人员有用的信息。

4.8 不要忽略异常

不要写空的catch块，确实可以忽略异常时，需要在catch块中注释原因