mirror of
https://github.com/sjsdfg/effective-java-3rd-chinese.git
synced 2025-01-10 04:10:15 +08:00
39 lines
4.8 KiB
Markdown
39 lines
4.8 KiB
Markdown
# 75. 在细节消息中包含失败一捕获信息
|
||
|
||
当程序由于未被捕获的异常而失败的时’候，系统会自动地打印出该异常的堆栈轨迹。在堆栈轨迹中包含该异常的字符串表示法 （string representation），即它的 toString 方法的调用结果。它通常包含该异常的类名，紧随其后的是细节消息 （detail message）。通常，这只是程序员或者网站可靠性工程师在调查软件失败原因时必须检查的信息。如果失败的情形不容易重现，要想获得更多的信息会非常困难，甚至是不可能的。因此，异常类型的 toString 方法应该尽可能多地返回有关失败原因的信息，这一点特别重要。换句话说，异常的字符串表示法应该捕获失败，以便于后续进行分析。
|
||
|
||
**为了捕获失败，异常的细节信息应该包含“对该异常有贡献”的所有参数和字段的值。** 例如， `IndexOutOfBoundsException` 异常的细节消息应该包含下界、上界以及没有落在界内的下标值。该细节消息提供了许多关于失败的信息。这三个值中任何一个或者全部都有可能是错的。实际的下标值可能小于下界或等于上界（「越界错误」），或者它可能是个无效值，太小或太大。下界也有可能大于上界（严重违反内部约束条件的一种情况） 。每一种情形都代表了不同的问题，如果程序员知道应该去查找哪种错误，就可以极大地加速诊断过程。
|
||
|
||
对安全敏感的信息有一条忠告。由于在诊断和修正软件问题的过程中，许多人都可以看见堆栈轨迹， **因此千万不要在细节消息中包含密码、密钥以及类似的信息！**
|
||
|
||
虽然在异常的细节消息中包含所有相关的数据是非常重要的，但是包含大量的描述信息往往没有什么意义。堆栈轨迹的用途是与源文件结合起来进行分析，它通常包含抛出该异常的确切文件和行数，以及堆校中所有其他方法调用所在的文件和行数。关于失败的冗长描述信息通常是不必要的，这些信息可以通过阅读源代码而获得。
|
||
|
||
异常的细节消息不应该与“用户层次的错误消息”混为一谈，后者对于最终用户而言必须是可理解的。与用户层次的错误消息不同，异常的字符串表示法主要是让程序员或者网站可靠性工程师用来分析失败的原因。因此，信息的内容比可读性要重要得多。用户层次的错误消息经常被本地化，而异常的细节消息则几乎没有被本地化。
|
||
|
||
为了确保在异常的细节消息中包含足够的失败－ 捕捉信息， 一种办法是在异常的构造器而不是字符串细节消息中引人这些信息。然后，有了这些信息，只要把它们放到消息描述中，就可以自动产生细节消息。例如 `IndexOutOfBoundsException` 使用如下构造器代替 `String` 构造器：
|
||
|
||
```java
|
||
/**
|
||
* 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 条） 。
|