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

最新推荐文章于 2023-03-20 00:14:02 发布

最新推荐文章于 2023-03-20 00:14:02 发布 · 200 阅读

文章标签：

#Java #读书 #编程 #SQL

java综合专栏收录该内容

7 篇文章

订阅专栏

本文详细阐述了异常处理的最佳实践，包括如何合理使用异常、区分受检异常与运行时异常、避免不必要的受检异常使用、优先使用标准异常、抛出与抽象相对应的异常、每个方法的异常文档、细节消息的丰富性、失败原子性的实现，以及如何正确处理异常，以提高代码质量和可维护性。

第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条：优先使用标准的异常

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

重用异常的好处：
1. 使你的API更加易于学习和使用，因为它与程序员已经熟悉的习惯用法是一致的
2. 可读性更好
3. 异常类越少，内存印迹就越小，装载这些类的时间开销也越小
常用异常
选择重用哪个异常并不总是那么精确，使用场合不排斥。

第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条：每个方法抛出的异常都要有文档

始终要单独地声明受检的异常，并且利用Javadoc@throws标记，准确第记录下抛出每个异常的条件，如果一个方法可能抛出多个异常类，则不要使用“快捷方式”声明它会抛出这些异常类的某个超类。永远不要声明一个方法“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;
}