chapter9.htm

基础书

其中最重要的行号在注释内标记出来。注意第17行没有设为注释行。它的输出结果如下：<br>
<br>
413页中程序<br>
<br>
因此，违例堆栈路径无论如何都会记住它的真正起点，无论自己被重复“掷”了好几次。<br>
若将第17行标注（变成注释行），而撤消对第18行的标注，就会换用fillInStackTrace()，结果如下：<br>
<br>
413页下程序<br>
<br>
由于使用的是fillInStackTrace()，第18行成为违例的新起点。<br>
针对g()和main()，Throwable类必须在违例规格中出现，因为fillInStackTrace()会生成一个Throwable对象的句柄。由于Throwable是Exception的一个基础类，所以有可能获得一个能够“掷”出的对象（具有Throwable属性），但却并非一个Exception（违例）。因此，在main()中用于Exception的句柄可能丢失自己的目标。为保证所有东西均井然有序，编译器强制Throwable使用一个违例规范。举个例子来说，下述程序的违例便不会在main()中被捕获到：<br>
<br>
414页上程序<br>
<br>
也有可能从一个已经捕获的违例重新“掷”出一个不同的违例。但假如这样做，会得到与使用fillInStackTrace()类似的效果：与违例起源地有关的信息会全部丢失，我们留下的是与新的throw有关的信息。如下所示：<br>
<br>
414-415页程序<br>
<br>
输出如下：<br>
<br>
415页程序<br>
<br>
最后一个违例只知道自己来自main()，而非来自f()。注意Throwable在任何违例规范中都不是必需的。<br>
永远不必关心如何清除前一个违例，或者与之有关的其他任何违例。它们都属于用new创建的、以内存堆为基础的对象，所以垃圾收集器会自动将其清除。<br>
<br>
9.3 标准Java违例<br>
Java包含了一个名为Throwable的类，它对可以作为违例“掷”出的所有东西进行了描述。Throwable对象有两种常规类型（亦即“从Throwable继承”）。其中，Error代表编译期和系统错误，我们一般不必特意捕获它们（除在特殊情况以外）。Exception是可以从任何标准Java库的类方法中“掷”出的基本类型。此外，它们亦可从我们自己的方法以及运行期偶发事件中“掷”出。<br>
为获得违例的一个综合概念，最好的方法是阅读由http://java.sun.com提供的联机Java文档（当然，首先下载它们更好）。为了对各种违例有一个大概的印象，这个工作是相当有价值的。但大家不久就会发现，除名字外，一个违例和下一个违例之间并不存在任何特殊的地方。此外，Java提供的违例数量正在日益增多；从本质上说，把它们印到一本书里是没有意义的。大家从其他地方获得的任何新库可能也提供了它们自己的违例。我们最需要掌握的是基本概念，以及用这些违例能够做什么。<br>
java.lang.Exception<br>
这是程序能捕获的基本违例。其他违例都是从它衍生出去的。这里要注意的是违例的名字代表发生的问题，而且违例名通常都是精心挑选的，可以很清楚地说明到底发生了什么事情。违例并不全是在java.lang中定义的；有些是为了提供对其他库的支持，如util，net以及io等——我们可以从它们的完整类名中看出这一点，或者观察它们从什么继承。例如，所有IO违例都是从java.io.IOException继承的。<br>
<br>
9.3.1 RuntimeException的特殊情况<br>
本章的第一个例子是：<br>
if(t == null)<br>
throw new NullPointerException();<br>
看起来似乎在传递进入一个方法的每个句柄中都必须检查null（因为不知道调用者是否已传递了一个有效的句柄），这无疑是相当可怕的。但幸运的是，我们根本不必这样做——它属于Java进行的标准运行期检查的一部分。若对一个空句柄发出了调用，Java会自动产生一个NullPointerException违例。所以上述代码在任何情况下都是多余的。<br>
这个类别里含有一系列违例类型。它们全部由Java自动生成，毋需我们亲自动手把它们包含到自己的违例规范里。最方便的是，通过将它们置入单独一个名为RuntimeException的基础类下面，它们全部组合到一起。这是一个很好的继承例子：它建立了一系列具有某种共通性的类型，都具有某些共通的特征与行为。此外，我们没必要专门写一个违例规范，指出一个方法可能会“掷”出一个RuntimeException，因为已经假定可能出现那种情况。由于它们用于指出编程中的错误，所以几乎永远不必专门捕获一个“运行期违例”——RuntimeException——它在默认情况下会自动得到处理。若必须检查RuntimeException，我们的代码就会变得相当繁复。在我们自己的包里，可选择“掷”出一部分RuntimeException。<br>
如果不捕获这些违例，又会出现什么情况呢？由于编译器并不强制违例规范捕获它们，所以假如不捕获的话，一个RuntimeException可能过滤掉我们到达main()方法的所有途径。为体会此时发生的事情，请试试下面这个例子：<br>
<br>
417页上程序<br>
<br>
大家已经看到，一个RuntimeException（或者从它继承的任何东西）属于一种特殊情况，因为编译器不要求为这些类型指定违例规范。<br>
输出如下：<br>
<br>
java.lang.RuntimeException: From f()<br>
at NeverCaught.f(NeverCaught.java:9)<br>
at NeverCaught.g(NeverCaught.java:12)<br>
at NeverCaught.main(NeverCaught.java:15)<br>
<br>
所以答案就是：假若一个RuntimeException获得到达main()的所有途径，同时不被捕获，那么当程序退出时，会为那个违例调用printStackTrace()。<br>
注意也许能在自己的代码中仅忽略RuntimeException，因为编译器已正确实行了其他所有控制。因为RuntimeException在此时代表一个编程错误：<br>
(1) 
一个我们不能捕获的错误（例如，由客户程序员接收传递给自己方法的一个空句柄）。<br>
(2) 作为一名程序员，一个应在自己的代码中检查的错误（如ArrayIndexOutOfBoundException，此时应注意数组的大小）。<br>
可以看出，最好的做法是在这种情况下违例，因为它们有助于程序的调试。<br>
另外一个有趣的地方是，我们不可将Java违例划分为单一用途的工具。的确，它们设计用于控制那些讨厌的运行期错误——由代码控制范围之外的其他力量产生。但是，它也特别有助于调试某些特殊类型的编程错误，那些是编译器侦测不到的。<br>
<br>
9.4 创建自己的违例<br>
并不一定非要使用Java违例。这一点必须掌握，因为经常都需要创建自己的违例，以便指出自己的库可能生成的一个特殊错误——但创建Java分级结构的时候，这个错误是无法预知的。<br>
为创建自己的违例类，必须从一个现有的违例类型继承——最好在含义上与新违例近似。继承一个违例相当简单：<br>
<br>
418-419页程序<br>
<br>
继承在创建新类时发生：<br>
<br>
419页上程序<br>
<br>
这里的关键是“extends Exception”，它的意思是：除包括一个Exception的全部含义以外，还有更多的含义。增加的代码数量非常少——实际只添加了两个构建器，对MyException的创建方式进行了定义。请记住，假如我们不明确调用一个基础类构建器，编译器会自动调用基础类默认构建器。在第二个构建器中，通过使用super关键字，明确调用了带有一个String参数的基础类构建器。<br>
该程序输出结果如下：<br>
<br>
419页下程序<br>
<br>
可以看到，在从f()“掷”出的MyException违例中，缺乏详细的消息。<br>
创建自己的违例时，还可以采取更多的操作。我们可添加额外的构建器及成员：<br>
<br>
419-421页程序<br>
<br>
此时添加了一个数据成员i；同时添加了一个特殊的方法，用它读取那个值；也添加了一个额外的构建器，用它设置那个值。输出结果如下：<br>
<br>
421页上程序<br>
<br>
由于违例不过是另一种形式的对象，所以可以继续这个进程，进一步增强违例类的能力。但要注意，对使用自己这个包的客户程序员来说，他们可能错过所有这些增强。因为他们可能只是简单地寻找准备生成的违例，除此以外不做任何事情——这是大多数Java库违例的标准用法。若出现这种情况，有可能创建一个新违例类型，其中几乎不包含任何代码：<br>
//: SimpleException.java<br>
class SimpleException extends Exception {<br>
} ///:~<br>
它要依赖编译器来创建默认构建器（会自动调用基础类的默认构建器）。当然，在这种情况下，我们不会得到一个SimpleException(String)构建器，但它实际上也不会经常用到。<br>
<br>
9.5 违例的限制<br>
覆盖一个方法时，只能产生已在方法的基础类版本中定义的违例。这是一个重要的限制，因为它意味着与基础类协同工作的代码也会自动应用于从基础类衍生的任何对象（当然，这属于基本的OOP概念），其中包括违例。<br>
下面这个例子演示了强加在违例身上的限制类型（在编译期）：<br>
<br>
422-423页程序<br>
<br>
在Inning中，可以看到无论构建器还是event()方法都指出自己会“掷”出一个违例，但它们实际上没有那样做。这是合法的，因为它允许我们强迫用户捕获可能在覆盖过的event()版本里添加的任何违例。同样的道理也适用于abstract方法，就象在atBat()里展示的那样。<br>
“interface Storm”非常有趣，因为它包含了在Incoming中定义的一个方法——event()，以及不是在其中定义的一个方法。这两个方法都会“掷”出一个新的违例类型：RainedOut。当执行到“StormyInning 
extends”和“implements Storm”的时候，可以看到Storm中的event()方法不能改变Inning中的event()的违例接口。同样地，这种设计是十分合理的；否则的话，当我们操作基础类时，便根本无法知道自己捕获的是否正确的东西。当然，假如interface中定义的一个方法不在基础类里，比如rainHard()，它产生违例时就没什么问题。<br>
对违例的限制并不适用于构建器。在StormyInning中，我们可看到一个构建器能够“掷”出它希望的任何东西，无论基础类构建器“掷”出什么。然而，由于必须坚持按某种方式调用基础类构建器（在这里，会自动调用默认构建器），所以衍生类构建器必须在自己的违例规范中声明所有基础类构建器违例。<br>
StormyInning.walk()不会编译的原因是它“掷”出了一个违例，而Inning.walk()却不会“掷”出。若允许这种情况发生，就可让自己的代码调用Inning.walk()，而且它不必控制任何违例。但在以后替换从Inning衍生的一个类的对象时，违例就会“掷”出，造成代码执行的中断。通过强迫衍生类方法遵守基础类方法的违例规范，对象的替换可保持连贯性。<br>
覆盖过的event()方法向我们显示出一个方法的衍生类版本可以不产生任何违例——即便基础类版本要产生违例。同样地，这样做是必要的，因为它不会中断那些已假定基础类版本会产生违例的代码。差不多的道理亦适用于atBat()，它会“掷”出PopFoul——从Foul衍生出来的一个违例，而Foul违例是由atBat()的基础类版本产生的。这样一来，假如有人在自己的代码里操作Inning，同时调用了atBat()，就必须捕获Foul违例。由于PopFoul是从Foul衍生的，所以违例控制器（模块）也会捕获PopFoul。<br>
最后一个有趣的地方在main()内部。在这个地方，假如我们明确操作一个StormyInning对象，编译器就会强迫我们只捕获特定于那个类的违例。但假如我们上溯造型到基础类型，编译器就会强迫我们捕获针对基础类的违例。通过所有这些限制，违例控制代码的“健壮”程度获得了大幅度改善（注释③）。<br>
<br>
③：ANSI/ISO C++施加了类似的限制，要求衍生方法违例与基础类方法掷出的违例相同，或者从后者衍生。在这种情况下，C++实际上能够在编译期间检查违例规范。<br>
<br>
我们必须认识到这一点：尽管违例规范是由编译器在继承期间强行遵守的，但违例规范并不属于方法类型的一部分，后者仅包括了方法名以及自变量类型。因此，我们不可在违例规范的基础上覆盖方法。除此以外，尽管违例规范存在于一个方法的基础类版本中，但并不表示它必须在方法的衍生类版本中存在。这与方法的“继承”颇有不同（进行继承时，基础类中的方法也必须在衍生类中存在）。换言之，用于一个特定方法的“违例规范接口”可能在继承和覆盖时变得更“窄”，但它不会变得更“宽”——这与继承时的类接口规则是正好相反的。<br>
<br>
9.6 用finally清除<br>
无论一个违例是否在try块中发生，我们经常都想执行一些特定的代码。对一些特定的操作，经常都会遇到这种情况，但在恢复内存时一般都不需要（因为垃圾收集器会自动照料一切）。为达到这个目的，可在所有违例控制器的末尾使用一个finally从句（注释④）。所以完整的违例控制小节象下面这个样子：<br>
<br>
try {<br>
// 要保卫的区域：<br>
// 可能“掷”出A,B,或C的危险情况<br>
} catch (A a1) {<br>
// 控制器 A<br>
} catch (B b1) {<br>
// 控制器 B<br>
} catch (C c1) {<br>
// 控制器 C<br>
} finally {<br>
// 每次都会发生的情况<br>
}<br>
<br>
④：C++违例控制未提供finally从句，因为它依赖构建器来达到这种清除效果。<br>
<br>