欢迎大家关注 github.com/hsfxuebao/j… ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈
当充分发挥异常的优势时，它可以提高程序的可读性、可靠性和可维护性。如果使用不当，则会产生相反的效果。本章提供了有效使用异常的指南。
69. 仅在发生异常的条件下使用异常
有一天，如果你运气不好，你可能会偶然发现这样一段代码:
// Horrible abuse of exceptions. Don't ever do this!
try {
int i = 0;
while(true)
range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}
这段代码是做什么的？检查结果看来一点也不明显，这就是不使用它的充分理由(条目 67)。事实证明，这是一种用于循环遍历数组元素的非常错误的习惯用法。当试图访问数组边界之外的第一个数组元素时，无限循环通过抛出、捕获和忽略ArrayIndexOutOfBoundsException异常来终止。它应该等同于循环数组的标准习惯用法，任何Java程序员都可以一眼就能识别出来：
for (Mountain m : range)
m.climb();
那么为什么有人会使用基于异常的循环而不是尝试和正确的用法？ 根据错误推理提高性能是一种错误的尝试，因为虚拟机检查所有数组访问的边界，由编译器隐藏但仍然存在于for-each循环中的正常循环终止测试是多余的，应该避免。 这个推理有三个问题：
- 因为异常是为特殊情况设计的，所以JVM实现者几乎没有试图让它们像显式测试一样快。
- 将代码放在try-catch块中会抑制虚拟机实现可能执行的某些优化。
- 遍历数组的标准习惯用法不一定会导致冗余检查。许多虚拟机实现对它们进行了优化。
事实上，基于异常的习惯用法比标准用法慢得多。在我的机器上，100个元素的数组，基于异常的习惯用法的速度大约是标准习惯用法的两倍。
基于异常的循环不仅混淆了代码的目的，降低了代码的性能，而且不能保证它能正常工作。如果循环中存在bug，使用异常进行流控制可以掩盖该bug，从而大大增加调试过程的复杂性。假设循环体中的计算调用一个方法，该方法对一些不相关的数组执行越界访问。如果使用合理的循环习惯用法，该bug将生成一个未捕获的异常，导致线程立即终止，并带有完整的堆栈跟踪。如果使用错误的基于异常的循环，则会捕获与bug相关的异常，并将其误解为正常的循环终止。
这个示例说明的道理很简单：顾名思义，异常仅用于特殊情况; 它们永远不应该用于正常的控制流程。 通常来说，使用标准的、易于识别的习惯用法，而不是声称可以提供更好性能的过度聪明的技术。即使性能优势是真实存在的，但在稳步改进平台实现的情况下，这种优势也可能不复存在。然而，来自过度聪明的技术的细微缺陷和维护难题肯定会继续存在。
这个原则对API设计也有影响。一个设计良好的API不能强迫它的客户端为正常的控制流使用异常。只有在某些不可预知的条件下才能调用具有“状态依赖(state-dependent)”方法的类，通常应该有一个单独的“状态测试(state-testing)”方法，指示是否适合调用状态依赖方法。例如，Iterator接口具有依赖于状态的next方法和对应的状态测试方法hasNext。这支持使用传统for循环(以及for-each循环，其中内部使用了hasNext方法)在集合上迭代的标准习惯用法：
for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
Foo foo = i.next();
...
}
如果Iterator缺少hasNext方法，则客户端将被迫执行此操作：
// Do not use this hideous code for iteration over a collection!
try {
Iterator<Foo> i = collection.iterator();
while(true) {
Foo foo = i.next();
...
}
} catch (NoSuchElementException e) {
}
这数组迭代的例子非常类似于本条目一开始的那个例子。除了冗长和误导之外，基于异常的循环很可能执行得很差，并且可以掩盖系统中不相关部分中的bug。
提供单独的状态测试方法的另一种方式是，让依赖于状态的方法返回一个空的Optional值(条目 55)，或者在它不能执行所需的计算时返回一个区分值，比如null。
下面是一些指导原则，帮助你在状态测试方法，Optional的或区分的返回值之间进行选择。如果要在没有外部同步的情况下并发地访问对象，或者受制于外部引发的状态转换，则必须使用Optional的或可区分的返回值，因为在调用状态测试方法与其依赖于状态的方法之间的间隔内，对象的状态可能会发生变化。如果一个单独的状态测试方法将重复依赖于状态的方法的工作，那么性能问题可能要求使用一个Optional的或可区分的返回值。在所有其他条件相同的情况下，状态测试方法略优于区分的返回值。它提供了更好的可读性，而且不正确的使用可能更容易检测：如果忘记调用状态测试方法，依赖于状态的方法将抛出异常，使错误变得明显；如果忘记检查一个可区分的返回值，那么这个bug可能很微妙。这不是Optional返回值的问题。
总之，异常是针对特殊情况而设计的。不要将它们用于正常的控制流程，也不要编写强制其他人这样做的API。
70. 对可恢复条件使用已检查异常，对编程错误使用运行时异常
Java提供了三种可抛出异常对象:已检查异常（ checked exceptions）、运行时异常（runtime exceptions）和虚拟机错误（errors）。程序员们对什么时候使用每种抛出的异常比较困惑。虽然决策并不总是明确的，但是有一些通用规则可以提供有力的指导。
决定是否使用已检查异常或未检查异常的基本规则是：对于可以合理地预期调用者将从中恢复的条件，使用已检查异常。通过抛出一个已检查的异常，可以强制调用者在catch子句中处理异常，或者将其传播出去。因此，声明要抛出方法的每个已检查异常都有力地向API用户表明，关联的条件是调用该方法的一个可能的结果。
通过向用户提供已检查异常，API设计器提供了从异常条件中恢复的要求。用户可以通过捕获异常并忽略异常来无视这个要求，但这通常不是一个好主意(条目 77)。
有两种未检查的可抛出的异常：运行时异常和虚拟机错误。它们在行为上是一样的:都是可抛出的，通常不应该被捕获。如果程序抛出未检查的异常或错误，通常情况下是无法恢复的，继续执行的话弊大于利。如果程序没有捕捉到这样的可抛出的异常，会导致当前线程挂起或停止，并发出适当的错误消息。
使用运行时异常来指出编程错误。 绝大多数运行时异常表示违反了先决条件（precondition violation）。 违反先决条件的原因仅仅是客户端API无法遵守API规范建立的约定。 例如，数组访问的约定指定数组索引必须介于0和数组长度减去1之间）。 ArrayIndexOutOfBoundsException异常指出违反了此先决条件。
这个建议的一个问题是，你并不总是清楚是在处理可恢复的异常还是编程错误。例如，考虑资源耗尽的情况，这可能是由编程错误(如分配一个不合理的大数组)或真正的资源短缺造成的。如果资源枯竭是由于临时短缺或需求临时增加造成的，这种情况很可能是可以恢复的。对于API设计人员来说，判断给定的资源耗尽实例是否允许恢复是一个问题。如果你认为某个条件可能允许恢复，请使用已检查的异常；如果不能，则使用运行时异常。如果不清楚是否可以恢复，最好使用未检查的异常，原因将在条目 71中讨论。
虽然Java语言规范没有要求，但有一个强烈的约定，即保留错误（errors）以供JVM使用，以指示资源缺陷，不变性失败（invariant failures），以及其他无法继续执行的条件。 鉴于几乎普遍接受这种约定，最好不要实现任何新的Error子类。 因此，实现所有未经检查的可抛出异常应该是RuntimeException的子类（直接或间接子类）。 不仅不应该定义Error子类，而且除了AssertionError之外，也不应该抛出它们。
可以定义一个可抛出的异常，不是Exception、RuntimeException或Error的子类。JLS不直接处理这些可抛出类，而是隐式地指定它们作为普通的检查异常(它们是Exception的子类，但不是RuntimeException)。那么，什么时候应该使用这样的可抛出异常？总之，永远不会。与普通的检查异常相比，它们没有任何好处，只会让API的使用者感到困惑。
API设计者经常忘记异常是也是完全成熟的对象，可以在其上定义任意方法。此类方法的主要用途是提供捕获异常的代码，其中包含有关导致抛出异常的条件的其他信息。 在没有这样的方法的情况下，已知程序员解析异常的字符串表示以发现附加信息。 这是非常糟糕的做法（条目 12）。 可抛出的类很少指定其字符串表示的细节，因此字符串表示可能因实现而异，也可能因发布而异。 因此，解析异常的字符串表示的代码可能是不可移植且脆弱的。
因为检查异常通常表示可恢复的异常条件，所以对它们来说，提供信息的方法来帮助调用者从异常条件中恢复尤为重要。例如，假设当使用礼品卡购物的尝试由于资金不足而失败时，抛出一个已检查的异常。异常应该提供一个访问器方法来查询差额的数量。这会使调用者能够将金额传递给购物者。有关此主题的更多信息，请参见条目 75。
总而言之，为可恢复的异常条件抛出已检查异常，为编程错误抛出未检查异常。当有疑虑不确定时，抛出未检查的异常。不要定义任何既不是已检查异常也不是运行时异常的可抛出异常。提供已检查异常的方法，用来帮助恢复。
71. 避免不必要地使用检查异常
许多Java程序员不喜欢检查异常，但如果使用得当，他们可以改进API和程序。 与返回码和未检查异常不同，它们迫使程序员处理异常问题，增强可靠性。 也就是说，在API中过度使用检查异常会使它们使用起来不那么令人愉快。 如果方法抛出检查异常，则调用它的代码必须在一个或多个catch块中处理它们，或者声明抛出它们并向上传播。 无论哪种方式，它都会给API的使用者带来负担。这种负担在Java 8中加重了，因为抛出检查异常的方法不能直接在Stream中使用（条目45——48）。
如果不能通过正确使用API来防止异常情况，并且使用API的程序员在遇到异常时可以采取一些有用的操作，那么这种负担是合理的。除非满足这两个条件，否则可以使用未检查异常。作为最后的检验（litmus test），可以问问自己：程序员将如何处理异常。这是最好的办法吗?
} catch (TheCheckedException e) {
throw new AssertionError(); // Can't happen!
}
或者这样：
} catch (TheCheckedException e) {
e.printStackTrace(); // Oh well, we lose.
System.exit(1);
}
如果程序员不能做得更好，则需要一个未检查异常。
如果方法抛出的检查异常是惟一的，那么检查异常给程序员带来的额外负担就会大得多。如果还有其他方法，则该方法必须已经出现在try块中，并且最多需要另一个catch块。如果一个方法抛出单个检查异常，那么这个异常就是该方法必须出现在try块中，并且不能直接在Stream中使用。在这种情况下，有必要问问自己是否有办法避免检查异常。
消除检查异的最简单方法是返回所需结果类型的Optional(条目 55)。该方法只返回一个空的Optional，而不是抛出一个检查的异常。这种方法的缺点是，该方法不能返回任何详细说明其无法执行所需计算的额外信息。相反，异常具有描述性类型，并且可以导出方法来提供额外的信息(条目 70)。
还可以通过将抛出异常的方法分解为两个方法，将检查异常转换为未检查异常，第一个方法返回一个boolean值，表示是否抛出异常。 这个API重构将调用序列：
// 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
}
这种重构并不总是合适的，但是它可以使API更加舒适。 虽然后者调用序列并不比前者更漂亮，但重构的API更灵活。 如果程序员知道调用将成功，或者满足于让线程在失败时终止，那么重构也允许这个简单的调用序列：
obj.action(args);
如果怀疑普通的调用序列会成为常态，那么API重构可能是合适的。生成的API本质上与条目 69中的状态测试方法API，并且适用与相同的警告：如果要在没有外部同步的情况下同时访问对象，或者被外部转换状态，则此重构是不合适的，因为对象的状态可能是在对actionPermitted和action的调用之间进行更改。如果单独的actionPermitted方法会重复action方法的工作，则可能会因性能原因而排除重构。
总之，如果谨慎使用，检查异常可以提高程序的可靠性；当过度使用，会使API难以使用。如果调用者无法从失败中恢复，则抛出未检查异常。如果恢复是可能的，并且希望强制调用者处理异常条件，那么首先考虑返回Optional的。只有当在失败的情况下，无法提供充分的信息时，才应该抛出一个检查的异常。
72. 赞成使用标准异常
专家级程序员与经验较少的程序员之间的一个区别是，专家力争并通常实现高度的代码重用。代码重用是一件好事，异常也不例外。Java类库提供了一组异常，涵盖了大多数API的异常抛出需求。
重用标准异常有几个好处。其中最主要的是，它使你的API更容易学习和使用，因为它符合程序员已经熟悉的既定约定。其次，使用你的API的程序更容易阅读，因为它们不会因为不熟悉的异常而混乱。最后(也是最不重要的)，更少的异常类意味着更小的内存占用和更少的加载类的时间。
最常用的异常是IllegalArgumentException（条目 49）。 当调用者传入一个不合适的参数值时，通常抛出这个异常。 例如，如果调用者在表示某个操作重复次数的参数中传递了一个负数，则抛出此异常。
另一个常用的异常是IllegalStateException。 如果由于接收对象的状态而调用是非法的，则通常会抛出异常。 例如，如果调用者试图使用尚未正确初始化之前的对象时，则抛出这个异常。
可以说，每个错误的方法调用都可以归结为非法参数或状态，但是还有一些异常通常用于某些类型的非法参数和状态。如果调用者在禁止null值的参数中传递null，那么按照惯例，抛出NullPointerException，而不是IllegalArgumentException异常。类似地，如果调用者将表示索引的参数中的超出范围的值传递给序列，则应该抛出IndexOutOfBoundsException，而不是IllegalArgumentException。
另一个可重用异常是ConcurrentModificationException。如果一个对象被设计为由单个线程使用(或与外部同步)，并且检测到它正在被并发地修改，则应该抛出该对象。这个异常最多是一个提示，因为无法可靠地检测并发修改。
最后一个需要注意的标准异常是UnsupportedOperationException。如果对象不支持尝试的操作，则抛出此异常。它很少使用，因为大多数对象都支持它们的所有方法。此异常用于无法实现由其实现的接口定义的一个或多个Optional操作的类。例如，如果有人试图从仅支持追加（append-only ）的列表中删除元素，则将抛出此异常。
不要直接重用Exception、RuntimeException、Throwable或Error。将这些类视为抽象类。你不能对这些异常进行可靠的测试，因为它们是方法可能抛出的其他异常的父类。
此表总结了最常见的重用异常:
异常
使用场景
IllegalArgumentException
不合适的非null参数值
IllegalStateException
方法调用状态不适合的对象
NullPointerException
再禁止使用null的情况下参数值为null
IndexOutOfBoundsException
索引参数值越界
ConcurrentModificationException
在禁止并发修改对象的地方检测到该对象被并发修改
UnsupportedOperationException
对象不支持方法
虽然到目前为止，这些是最常见的重用异常，但是在环境允许的情况下也可以重用其他异常。例如，如果正在实现诸如复数或有理数之类的算术对象，那么重用ArithmeticException和NumberFormatException是合适的。如果一个异常符合你的需要，那么继续使用它，但前提是抛出它的条件与异常文档描述一致：重用必须基于文档化的语义，而不仅仅是基于名称。另外，如果想添加更多的细节，可以随意子类化标准异常(条目 75)，但是请记住异常是可序列化的(第12章)。这本身就是，如果没有充分理由，不要编写自己的异常类的原因。
选择重用哪个异常可能比较棘手，因为上面表格中的“使用场景”似乎并不相互排斥。考虑表示一副纸牌的对象的情况，假设有表示发一手牌的方法，该方法参数是一手牌的纸牌数量。如果调用者传递的值大于整副牌中剩余的牌的数量，则可以将其解释为IllegalArgumentException (handSize参数值过大)，或者是IllegalStateException(纸牌中包含的牌太少)。在这种情况下，规则是，如果没有参数值，则抛出IllegalArgumentException，否则抛出IllegalArgumentException异常。
73. 抛出合乎于抽象的异常
当一个方法抛出一个与它所执行的任务没有明显关联的异常时，这是令人不安的。在方法传播由低层（lower-level）抽象抛出的异常时，会经常发生这种情况。它不仅令人不安，而且用实现细节“污染”了上层的API。如果上层（higher layer）的实现在以后的版本中发生变化，那么它抛出的异常也会发生变化，可能会破坏现有的客户端程序。
为了避免这个问题，上层（higher layers）应该捕获低层（ lower-level ）的异常，并在它们的位置抛出可以用上层级别（higher-level ）抽象来解释的异常。这个习语被称为异常转译:
// Exception Translation
try {
... // Use lower-level abstraction to do our bidding
} catch (LowerLevelException e) {
throw new HigherLevelException(...);
}
以下的异常转转译的示例是来自AbstractSequentialList类，该类是List接口的骨架实现（skeletal implementation ）（条目 20）。 在此示例中，异常转译由List <E>接口中的get方法规范强制要求的：
/**
* Returns the element at the specified position in this list.
* @throws IndexOutOfBoundsException if the index is out of range
* ({@code index < 0 || index >= size()}).
*/
public E get(int index) {
ListIterator<E> i = listIterator(index);
try {
return i.next();
} catch (NoSuchElementException e) {
throw new IndexOutOfBoundsException("Index: " + index);
}
}
如果较低级别的异常可能有助于调试导致较高级别异常的问题，则需要一种称为异常链（exception chaining ）的特殊异常转译形式。低层异常(原因)传递给高层异常，高层异常提供一个访问器方法(Throwable的getCause方法)来检索低层异常:
// Exception Chaining
try {
... // Use lower-level abstraction to do our bidding
} catch (LowerLevelException cause) {
throw new HigherLevelException(cause);
}
高级异常的构造方法将原因传递给一个感知链（chaining-aware）的父类构造方法，因此它最终被传递给Throwable的一个感知链的构造方法，比如Throwable(Throwable):
// Exception with chaining-aware constructor
class HigherLevelException extends Exception {
HigherLevelException(Throwable cause) {
super(cause);
}
}
大多数标准异常都有感知链的构造方法。对于没有这样做的异常，可以使用Throwable的initCause方法设置原因。异常链接不仅允许你以编程方式访问原因(使用getCause)，而且还将原因的堆栈跟踪集成到更高级别异常的堆栈跟踪中。
虽然异常转译优于低层异常的无意识传播，但不应过度使用。 在可能的情况下，处理较低层异常的最佳方法是通过确保较低级别的方法成功执行来避免异常。 有时可以通过检查更高级别方法的参数的有效性，然后再将它们传递到较低层来完成此操作。
如果不可能防止来自较低层的异常，那么接下来最好的事情就是让较高层静默地解决这些异常，从而使较高级别方法的调用者与较低级别的问题隔离开来。 在这些情况下，使用某些适当的日志记录工具（如java.util.logging）记录异常可能是适当的。 这允许程序员调查问题，同时把使用者和客户端代码隔离开。
总之，如果无法阻止或处理较低层的异常，那么使用异常转译，除非较低级别的方法恰好保证其所有异常都适用于较高级别。 异常链接提供了两全其美的优势：它允许抛出适当的更高级别异常，同时可以捕获失败分析的根本原因（条目 75）。
74. 文档化每个方法抛出的所有异常
描述方法抛出的异常，是正确使用方法所需文档的重要部分。因此，花时间为每个方法抛出的所有异常建立文档是非常重要的(条目 56)。
始终单独声明检查异常，并使用Javadoc @throw标签，精确地记录每次抛出异常的条件。不要使用“快捷方式”声明一个方法抛出它可以抛出的多个异常类的超类。作为一个极端的例子，不要声明公共方法抛出Exception类，或者更糟，抛出Throwable类。除了拒绝向方法的用户提供关于它能够抛出的异常的任何指导之外，这样的声明还极大地阻碍了方法的使用，因为它极大掩盖了可能在相同上下文中抛出的任何其他异常。这个建议的一个例外情况是main方法，它可以安全地声明为抛出Exception类，因为它只被虚拟机调用。
虽然Java语言不要求程序员声明方法能够抛出的未检查异常（unchecked exceptions），但明智的做法是像检查异常一样仔细地在文档中记录它们。未检查异常通常表示编程错误(条目 70)，让程序员熟悉他们可能犯的所有错误可以帮助他们避免犯这些错误。方法可以抛出的未检查异常的良好文档列表有效地描述了成功执行的先决条件。每个公共方法的文档都必须描述它的先决条件(条目 56)，记录它的未检查异常是满足这个需求的最佳方法。
特别重要的是，接口中的方法要在文档中记录它们可能抛出的未检查异常。此文档构成接口通用约定的一部分，并支持接口的多个实现之间的公共行为。
使用Javadoc @throw标签记录方法可以抛出的每个异常，但是不要对未检查的异常使用throws关键字。重要的是，使用你的API的程序员必须知道哪些方法是检查异常，哪些是未检查异常，因为程序员的责任在这两种情况下有所不同。Javadoc @throws标签生成的文档在方法声明中没有对应的抛出子句，这向程序员提供了一个强烈的视觉暗示，说明该异常是未检查异常。
应该注意的是，在文档中记录每个方法可以抛出的所有未检查异常是理想的，在现实世界中并不总是可以实现。当类进行修订时，如果将导出的方法修改为抛出额外的未检查异常，这并不违反源代码或二进制兼容性。假设一个类从另外一个独立编写的类调用一个方法。第一个类的作者可能会仔细记录所有的每个方法抛出未经检查的异常，但是如果第二个类的作者修改为额外的未经检查的异常，很可能第一个类(未经修订)将传播新的未经检查异常，尽管没有文档记录它们。
如果一个类中的许多方法出于相同的原因引发异常，可以在类的文档注释中记录异常，而不是为每个方法单独记录异常。一个常见的例子是NullPointerException。类的文档注释可以这样说：“如果在任何参数中传递了null对象引用，该类中的所有方法都会抛出NullPointerException”，或者类似的描述。
总之，在文档中记录你所编写的每个方法可能引发的每个异常。对于未检查异常、检查异常以及抽象方法和具体实现方法中都是如此。这个文档应该在文档注释中采用@throws标签的形式。在方法的throws子句中分别声明每个检查异常，但不要声明未检查异常。如果未记录方法可能抛出的异常，其他人将很难或不可能有效地使用你的类和接口。
75. 在详细信息中包含失败捕获信息
当程序由于未捕获异常而失败时，系统自动打印出异常的堆栈轨迹 。堆栈轨迹包含异常的字符串表示，这是调用其toString方法的结果。这通常包括异常的类名及其详细信息。通常，这是程序员或网站可靠性工程师在调查软件故障时所掌握的唯一信息。如果失败不容易重现，则可能很难或不可能获得更多信息。因此，异常的toString方法返回尽可能多的关于失败原因的信息是非常重要的。换句话说，异常的详细信息应该捕获失败，以便后续分析。
要捕获失败，异常的详细消息应包含导致异常的所有参数和属性的值。 例如，IndexOutOfBoundsException的详细消息应包含下限，上限和不能在边界之间的索引值。 这些信息告诉了很多关于失败的信息。 三个值中的任何一个或全部都可能是错误的。 索引可能比下限小一或等于上限（“fencepost error”），或者它可能是一个野值（wild value），太低或太高。 下限可能大于上限（严重的内部不变失败）。 这些情况中的每一种都指向一个不同的问题，如果你知道正在寻找什么样的错误，它将极大地帮助你进行诊断。
有一个与安全敏感信息有关的警告。因为堆栈轨迹可能在诊断和修复软件问题的过程中被许多人看到，所以不要包括密码、加密密钥等详细信息。
虽然在异常的详细信息中包含所有相关数据非常重要，但通常不需要包含大量的不相关的信息。堆栈轨迹与文档一起分析，如果需要，再与源代码一起分析。它通常包含抛出异常的确切文件和行号，以及堆栈上所有其他方法调用的文件和行号。冗长的描述失败信息是多余的；可以通过阅读文档和源代码来收集信息。
不应将异常的详细消息与用户级错误消息混淆，后者必须能够为最终被用户理解。 与用户级错误消息不同，详细消息主要是为了程序员或网站可靠性工程师在分析故障时的原因。 因此，信息内容远比可读性重要。 用户级错误消息通常是本地化的，而异常详细消息很少被本地化。
确保异常在其详细消息中包含足够的失败捕获信息的一种方法是，在其构造方法中，而不是字符串详细消息中要求此信息。 然后可以自动生成详细消息中包括该信息。 例如，IndexOutOfBoundsException可能有一个如下所示的构造方法，而不是String构造方法：
**
* Constructs an IndexOutOfBoundsException.
*
* @param lowerBound the lowest legal index value
* @param upperBound the highest legal index value plus one
* @param index the actual index value
*/
public IndexOutOfBoundsException(int lowerBound, int upperBound,
int index) {
// Generate a detail message that captures the failure
super(String.format(
"Lower bound: %d, Upper bound: %d, Index: %d",
lowerBound, upperBound, index));
// Save failure information for programmatic access
this.lowerBound = lowerBound;
this.upperBound = upperBound;
this.index = index;
}
从Java 9开始，IndexOutOfBoundsException最终获得了一个接受int值index参数的构造方法，但遗憾的是它删除了lowerBound和upperBound两个参数。更普遍地说，Java类库并没有大量使用这个习惯用法，但是强烈推荐使用它。它使程序员很容易抛出异常来捕获失败。事实上，它使程序员不想捕获失败都难！实际上，这个习惯用法将代码集中在异常类中生成高质量的详细信息，而不是要求该类的每个使用者都冗余地生成详细信息。
如条目 70所示，异常可能适合为其失败捕获信息（上例中的lowerBound，upperBound和index）提供访问器方法。 在检查异常上提供此类访问器方法比未检查异常更为重要，因为故障捕获信息可用于从故障中恢复。 程序员可能希望以编程方式访问未检查异常的细节，这种情况很少见（尽管也是可以想象的）。 但是，即使对于未检查异常情况，最好根据一般原则提供这些方法的访问器（条目 12，第57页）。
76. 争取保持失败原子性
在对象抛出异常之后，通常希望对象仍然处于定义良好的可用状态，即使失败发生在执行操作中。对于检查异常尤其如此，调用者希望从检查异常中恢复。一般来说，失败的方法调用应该使对象处于调用之前的状态。具有此属性的方法称为失败原子性（ failure-atomic）。
有几种方法可以达到这种效果。最简单的方法是设计不可变对象(条目 17)。如果对象是不可变的，则失败原子性是必然的。如果一个操作失败，它可能会阻止创建一个新对象，但是它不会让一个现有对象处于不一致的状态，因为每个对象的状态在创建时是一致的，并且在创建后不能修改。
对于对可变对象进行操作的方法，实现失败原子性的最常用方法是：在执行操作之前检查参数的有效性（条目 49）。 这导致在对象修改开始之前就会抛出大多数异常。 例如，考虑条目 7中的Stack.pop方法：
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}
如果取消了初始大小检查，当该方法试图从空栈中弹出元素时，仍然会抛出异常。但是，这会使size属性处于不一致的(负数)状态，导致以后对对象的任何方法调用失败。此外，pop方法抛出的ArrayIndexOutOfBoundsException针对抽象来讲是不合适的。(条目 73)。
实现失败原子性的一种密切相关的方法是对计算进行排序，以便任何可能失败的部分在修改对象的部分之前发生。 在执行部分计算时进行参数检查，此方法是前一个方法的自然扩展。 例如，考虑TreeMap的情况，其元素按照某种顺序排序。 为了向TreeMap添加元素，元素必须是可以使用TreeMap的顺序进行比较的类型。 在以任何方式修改tree之前，尝试添加错误键的元素自然会因为在tree中搜索元素失败而导致ClassCastException异常。
实现失败原子性的第三种方法是，在对象的临时拷贝上执行操作，并在操作完成后用临时拷贝替换对象的内容。当数据存储在临时数据结构中后，计算可以更快地执行时，这种方法自然会出现。例如，一些排序方法在排序之前将其输入列表拷贝到数组中，以降低访问排序内循环中的元素的成本。这样做是为了提高性能，但是作为一个额外的好处，它确保如果排序失败，输入列表保持不变。
实现失败原子性的最后的方法是，编写恢复代码（recovery code），但这种做法并不长用，该代码拦截在操作中发生的失败，并使对象将其状态回滚到操作开始之前的点。 此方法主要用于持久性的（基于磁盘）的数据结构。
虽然失败原子性通常是可取的，但它并不总是可以实现的。例如，如果两个线程试图在没有适当同步的情况下并发地修改同一个对象，那么该对象可能会处于不一致的状态。因此，如果假定在捕捉到ConcurrentModificationException之后对象仍然可用，那就错了。错误是不可恢复的，所以方法在抛出AssertionError时，甚至不需要尝试保存失败原子性。
即使在可能存在实现失败原子性的情况下，也并非总是可取的。 对于某些操作，它会显着增加成本或复杂性。 也就是说，一旦你意识到这个问题，通常都可以自由而轻松地做到失败原子性。
总之，作为规则，任何生成的异常都是方法规范的一部分，应该使对象处于方法调用之前的状态。 违反此规则的地方，API文档应清楚地指出该对象将保留在哪种状态。遗憾的是，许多现有的API文档无法实现这一理想。
77. 不要忽略异常
虽然这一建议似乎显而易见，但它经常被违反，因此值得重复提及。当API的设计人员声明一个抛出异常的方法时，他们试图告诉你一些事情。不要忽忽略它！在方法调用的周围加上一条try语句，其catch块为空，这样就很容易忽略了异常：
// Empty catch block ignores exception - Highly suspect!
try {
...
} catch (SomeException e) {
}
空的catch块违背了异常的初衷，而异常的目的是强迫处理异常情况。忽略异常类似于忽略火灾警报——关掉它，这样其他人就没有机会看到是否真的发生了火灾。你可能侥幸逃脱，或者结果可能是灾难性的。每当你看到一个空的catch块，你的脑海中就应该响起警报。
但在某些情况下，忽略异常是合适的。例如，在关闭FileInputStream时，它可能是合适的。你没有更改文件的状态，因此不需要执行任何恢复操作，并且已经从文件中读取了所需的信息，因此没有理由中止正在进行的操作。记录异常可能是明智的，这样如果这些异常经常发生，你就可以调查这个问题。如果选择忽略异常，catch块应该包含一条解释为什么这样做是合适的注释，并且变量应该被命名为ignore:
Future<Integer> f = exec.submit(planarMap::chromaticNumber);
int numColors = 4; // Default; guaranteed sufficient for any map
try {
numColors = f.get(1L, TimeUnit.SECONDS);
} catch (TimeoutException | ExecutionException ignored) {
// Use default: minimal coloring is desirable, not required
}
本条目中的建议同样适用于检查异常和未检查异常。不管异常是表示可预测的异常情况还是编程错误，用空catch块忽略它将导致程序在错误面前默默地执行下去。然后，程序可能会在未来的任意时间失败，在代码中与问题根源没有明显关系的某个点上。正确处理异常可以完全避免失败。仅仅让异常向外传播至少会导致程序迅速失败，保留信息以帮助调试失败的原因。
