按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
1。 中断与恢复
在违例控制理论中，共存在两种基本方法。在“中断”方法中（Java 和 C＋＋提供了对这种方法的支持），我
们假定错误非常关键，没有办法返回违例发生的地方。无论谁只要“掷”出一个违例，就表明没有办法补救
错误，而且也不希望再回来。
另一种方法叫作“恢复”。它意味着违例控制器有责任来纠正当前的状况，然后取得出错的方法，假定下一
次会成功执行。若使用恢复，意味着在违例得到控制以后仍然想继续执行。在这种情况下，我们的违例更象
一个方法调用——我们用它在 Java 中设置各种各样特殊的环境，产生类似于“恢复”的行为（换言之，此时
不是“掷”出一个违例，而是调用一个用于解决问题的方法）。另外，也可以将自己的try 块置入一个
while 循环里，用它不断进入 try 块，直到结果满意时为止。
从历史的角度看，若程序员使用的操作系统支持可恢复的违例控制，最终都会用到类似于中断的代码，并跳
过恢复进程。所以尽管“恢复”表面上十分不错，但在实际应用中却显得困难重重。其中决定性的原因可能
是：我们的控制模块必须随时留意是否产生了违例，以及是否包含了由产生位置专用的代码。这便使代码很
难编写和维护——大型系统尤其如此，因为违例可能在多个位置产生。
9。2。3 违例规范
在Java 中，对那些要调用方法的客户程序员，我们要通知他们可能从自己的方法里“掷”出违例。这是一种
有礼貌的做法，只有它才能使客户程序员准确地知道要编写什么代码来捕获所有潜在的违例。当然，若你同
时提供了源码，客户程序员甚至能全盘检查代码，找出相应的 throw 语句。但尽管如此，通常并不随同源码
提供库。为解决这个问题，Java 提供了一种特殊的语法格式（并强迫我们采用），以便礼貌地告诉客户程序
员该方法会“掷”出什么违例，令对方方便地加以控制。这便是我们在这里要讲述的“违例规范”，它属于
方法声明的一部分，位于自变量（参数）列表的后面。
违例规范采用了一个额外的关键字：throws；后面跟随全部潜在的违例类型。因此，我们的方法定义看起来
应象下面这个样子：
void f（） throws tooBig； tooSmall； divZero ｛ //。。。
若使用下述代码：
265
…………………………………………………………Page 267……………………………………………………………
void f（） ＇ // 。。。
它意味着不会从方法里“掷”出违例（除类型为RuntimeException 的违例以外，它可能从任何地方掷出——
稍后还会详细讲述）。
但不能完全依赖违例规范——假若方法造成了一个违例，但没有对其进行控制，编译器会侦测到这个情况，
并告诉我们必须控制违例，或者指出应该从方法里“掷”出一个违例规范。通过坚持从顶部到底部排列违例
规范，Java 可在编译期保证违例的正确性（注释②）。
②：这是在 C＋＋违例控制基础上一个显著的进步，后者除非到运行期，否则不会捕获不符合违例规范的错
误。这使得 C＋＋的违例控制机制显得用处不大。
我们在这个地方可采取欺骗手段：要求“掷”出一个并没有发生的违例。编译器能理解我们的要求，并强迫
使用这个方法的用户当作真的产生了那个违例处理。在实际应用中，可将其作为那个违例的一个“占位符”
使用。这样一来，以后可以方便地产生实际的违例，毋需修改现有的代码。
9。2。4 捕获所有违例
我们可创建一个控制器，令其捕获所有类型的违例。具体的做法是捕获基础类违例类型Exception （也存在
其他类型的基础违例，但Exception 是适用于几乎所有编程活动的基础）。如下所示：
catch（Exception e） ｛
System。out。println（〃caught an exception〃）；
｝
这段代码能捕获任何违例，所以在实际使用时最好将其置于控制器列表的末尾，防止跟随在后面的任何特殊
违例控制器失效。
对于程序员常用的所有违例类来说，由于 Exception 类是它们的基础，所以我们不会获得关于违例太多的信
息，但可调用来自它的基础类Throwable 的方法：
String getMessage（）
获得详细的消息。
String toString（）
返回对Throwable 的一段简要说明，其中包括详细的消息（如果有的话）。
void printStackTrace（）
void printStackTrace（PrintStream）
打印出Throwable 和 Throwable 的调用堆栈路径。调用堆栈显示出将我们带到违例发生地点的方法调用的顺
序。
第一个版本会打印出标准错误，第二个则打印出我们的选择流程。若在Windows 下工作，就不能重定向标准
错误。因此，我们一般愿意使用第二个版本，并将结果送给System。out；这样一来，输出就可重定向到我们
希望的任何路径。
除此以外，我们还可从 Throwable 的基础类Object （所有对象的基础类型）获得另外一些方法。对于违例控
制来说，其中一个可能有用的是getClass（），它的作用是返回一个对象，用它代表这个对象的类。我们可依
次用getName（）或toString（）查询这个Class 类的名字。亦可对 Class 对象进行一些复杂的操作，尽管那些
操作在违例控制中是不必要的。本章稍后还会详细讲述 Class 对象。
下面是一个特殊的例子，它展示了 Exception 方法的使用（若执行该程序遇到困难，请参考第3 章3。1。2 小
节“赋值”）：
//： ExceptionMethods。java
// Demonstrating the Exception Methods
package c09；
public class ExceptionMethods ｛
public static void main（String＇＇ args） ｛
try ｛
266
…………………………………………………………Page 268……………………………………………………………
throw new Exception（〃Here's my Exception〃）；
｝ catch（Exception e） ｛
System。out。println（〃Caught Exception〃）；
System。out。println（
〃e。getMessage（）： 〃 ＋ e。getMessage（））；
System。out。println（
〃e。toString（）： 〃 ＋ e。toString（））；
System。out。println（〃e。printStackTrace（）：〃）；
e。printStackTrace（）；
｝
｝
｝ ///：~
该程序输出如下：
Caught Exception
e。getMessage（）： Here's my Exception
e。toString（）： java。lang。Exception： Here's my Exception
e。printStackTrace（）：
java。lang。Exception： Here's my Exception
at ExceptionMethods。main
可以看到，该方法连续提供了大量信息——每类信息都是前一类信息的一个子集。
9。2 。5 重新“掷”出违例
在某些情况下，我们想重新掷出刚才产生过的违例，特别是在用Exception 捕获所有可能的违例时。由于我
们已拥有当前违例的句柄，所以只需简单地重新掷出那个句柄即可。下面是一个例子：
catch（Exception e） ｛
System。out。println（〃一个违例已经产生〃）；
throw e；
｝
重新“掷”出一个违例导致违例进入更高一级环境的违例控制器中。用于同一个 try 块的任何更进一步的
catch 从句仍然会被忽略。此外，与违例对象有关的所有东西都会得到保留，所以用于捕获特定违例类型的
更高一级的控制器可以从那个对象里提取出所有信息。
若只是简单地重新掷出当前违例，我们打印出来的、与printStackTrace（）内的那个违例有关的信息会与违
例的起源地对应，而不是与重新掷出它的地点对应。若想安装新的堆栈跟踪信息，可调用
fillInStackTrace（），它会返回一个特殊的违例对象。这个违例的创建过程如下：将当前堆栈的信息填充到
原来的违例对象里。下面列出它的形式：
//： Rethrowing。java
// Demonstrating fillInStackTrace（）
public class Rethrowing ｛
public static void f（） throws Exception ｛
System。out。println（
〃originating the exception in f（）〃）；
throw new Exception（〃thrown from f（）〃）；
｝
public static void g（） throws Throwable ｛
try ｛
f（）；
｝ catch（Exception e） ｛
267
…………………………………………………………Page 269……………………………………………………………
System。out。println（
〃Inside g（）； e。printStackTrace（）〃）；
e。printStackTrace（）；
throw e； // 17
// throw e。fillInStackTrace（）； // 18
｝
｝
public static void
main（String＇＇ args） throws Throwable ｛
try ｛
g（）；
｝ catch（Exception e） ｛
System。out。println（
〃Caught in main； e。printStackTrace（）〃）；
e。printStackTrace（）；
｝
｝
｝ ///：~
其中最重要的行号在注释内标记出来。注意第 17行没有设为注释行。它的输出结果如下：
originating the exception in f（）
Inside g（）； e。printStackTrace（）
java。lang。Exception： thrown from f（）
at Rethrowing。f（Rethrowing。java：8）
at Rethrowing。g（Rethrowing。java：12）
at Rethrowing。main（Rethrowing。java：24）
Caught in main； e。printStackTrace（）
java。lang。Exception： thrown from f（）
at Rethrowing。f（Rethrowing。java：8）
at Rethrowing。g（Rethrowing。java：12）
at Rethrowing。main（Rethrowing。java：24）
因此，违例堆栈路径无论如何都会记住它的真正起点，无论自己被重复“掷”了好几次。
若将第 17 行标注（变成注释行），而撤消对第 18 行的标注，就会换用fillInStackTrace（），结果如下：