24.JAVA编程思想——违例差错控制

24.JAVA编程思想——违例差错控制

Java 的基本原理就是“形式错误的代码不会执行”。

与C++类似，捕获错误最理想的是在编译期间，最好在试图执行程序曾经。然而。并不是全部错误都能在编译期间侦測到。有些问题必须在执行期间解决。让错误的缔结者通过一些手续向接收者传递一些适当的信息，使其知道该怎样正确地处理遇到的问题。

在C++和其它早期语言中，可通过几种手续来达到这个目的。并且它们一般是作为一种规定建立起来的，而非作为程序设计语言的一部分。典型地，我们须要返回一个值或设置一个标志（位），接收者会检查这些值或标志，推断详细发生了什么事情。然而，随着时间的流逝，最终发现这样的做法会助长那些使用一个库的程序猿的麻痹情绪。

他们往往会这样想：“是的。错误可能会在其它人的代码中出现。但不会在我的代码中”。

这样的后果便是他们一般不检查是否出现了错误（有时出错条件确实显得太愚蠢。不值得检验）。还有一方面，若每次调用一个方法时都进行全面、仔细的错误检查，那么代码的可读性也可能大幅度减少。

由于程序猿可能仍然在用这些语言维护自己的系统，所以他们应该对此有着深刻的体会：若按这样的方式控制错误，那么在创建大型、健壮、易于维护的程序时，肯定会遇到不小的阻挠。解决办法是在错误控制中排除全部偶然性。强制格式的正确。这样的方法实际已有非常长的历史，由于早在60年代便在操作系统里採用了“违例控制”手段；甚至能够追溯到BASIC
语言的on error goto 语句。但C++的违例控制建立在Ada 的基础上，而Java 又主要建立在C++的基础上（虽然它看起来更象ObjectPascal）。

“违例”（Exception）这个词表达的是一种“例外”情况，亦即正常情况之外的一种“异常”。在问题发生的时候。我们可能不知详细该怎样解决，但肯定知道已不能不顾一切地继续下去。

此时，必须坚决地停下来。并由某人、某地指出发生了什么事情，以及该採取何种对策。但为了真正解决这个问题，当地可能并没有足够多的信息。

因此，我们须要将其移交给更级的负责人。令其作出正确的决定（类似一个命令链）。

违例机制的还有一项优点就是可以简化错误控制代码。我们再也不用检查一个特定的错误，然后在程序的多处地方对其进行控制。

此外，也不须要在方法调用的时候检查错误（由于保证有人能捕获这里的错误）。我们仅仅须要在一个地方处理问题：“违例控制模块”或者“违例控制器”。这样可有效降低代码量。并将那些用于描写叙述详细操作的代码与专门纠正错误的代码分隔开。普通情况下，用于读取、写入以及调试的代码会变得更富有条理。

因为违例控制是由Java 编译器强行实施的，所以毋需深入学习违例控制，便可正确使用本书编写的大量样例。

1     基本违例

“违例条件”表示在出现什么问题的时候应中止方法或作用域的继续。

为了将违例条件与普通问题区分开。违例条件是很重要的一个因素。在普通问题的情况下，我们在当地已拥有足够的信息，可在某种程度上解决碰到的问题。

而在违例条件的情况下，却无法继续下去，由于当地没有提供解决这个问题所需的足够多的信息。此时，我们能做的唯一事情就是跳出当地环境，将那个问题托付给一个更高级的负责人。这便是出现违例时出现的情况。

一个简单的样例是“除法”。如可能被零除，就有必要进行检查，确保程序不会冒进，并在那种情况下运行除法。

但详细通过什么知道分母是零呢？在那个特定的方法里。在我们试图解决的那个问题的环境中，我们也许知道该怎样对待一个零分母。但假如它是一个没有预料到的值，就不能对其进行处理。所以必须产生一个违例，而非不顾一切地继续运行下去。

产生一个违例时，会发生几件事情。首先，依照与创建Java 对象一样的方法创建违例对象：在内存“堆”里，使用new 来创建。随后，停止当前运行路径（记住不可沿这条路径继续下去）。然后从当前的环境中释放出违例对象的句柄。此时，违例控制机制会接管一切。并開始查找一个恰当的地方，用于继续程序的运行。这个恰当的地方便是“违例控制器”，它的职责是从问题中恢复，使程序要么尝试还有一条运行路径，要么简单地继续。

作为产生违例的一个简单演示样例，大家可思考一个名为t 的对象句柄。有些时候，程序可能传递一个尚未初始化的句柄。所以在用那个对象句柄调用一个方法之前。最好进行一番检查。

可将与错误有关的信息发送到一个更大的场景中。方法是创建一个特殊的对象，用它代表我们的信息，并将其“掷”（Throw）出我们当前的场景之外。这就叫作“产生一个违例”或者“掷出一个违例”。以下是它的大概形式：

if(t == null)

throw newNullPointerException();

这样便“掷”出了一个违例。在当前场景中。它使我们能放弃进一步解决该问题的企图。该问题会被转移到其它更恰当的地方解决。准确地说，那个地方不久就会显露出来。

1.1     违例自变量

和Java 的其它不论什么对象一样，须要用new 在内存堆里创建违例，并需调用一个构建器。

在全部标准违例中，存在着两个构建器：第一个是默认构建器。第二个则需使用一个字串自变量，使我们能在违例里置入相关信息：

if(t == null)

throw newNullPointerException("t = null");

字串可用各种方法提取出来，就象稍后会展示的那样。

在这儿，keywordthrow 会象变戏法一样做出一系列不可思议的事情。它首先运行new 表达式。创建一个不在程序常规运行范围之内的对象。并且理所当然，会为那个对象调用构建器。随后。对象实际会从方法中返回——虽然对象的类型通常并非方法设计为返回的类型。为深入理解违例控制，可将其想象成还有一种返回机制——可是不要在这个问题上深究，否则会遇到麻烦。通过“掷”出一个违例，亦可从原来的作用域中退出。

可是会先返回一个值。再退出方法或作用域。

可是，与普通方法返回的相似性到此便所有结束了，由于我们返回的地方与从普通方法调用中返回的地方是迥然有异的。

可依据须要掷出不论什么类型的“可掷”对象。典型情况下，我们要为每种不同类型的错误“掷”出一类不同的违例。

思路是在违例对象以及挑选的违例对象类型中保存信息，所以在更大场景中的某个人可知道怎样对待我们的违例（通常，唯一的信息是违例对象的类型，而违例对象中保存的没什么意义）。

2     违例的捕获

若某个方法产生一个违例，必须保证该违例能被捕获，并获得正确对待。对于Java 的违例控制机制，它的一个优点就是同意我们在一个地方将精力集中在要解决的问题上，然后在还有一个地方对待来自那个代码内部的错误。

为理解违例是怎样捕获的。首先必须掌握“警戒区”的概念。

它代表一个特殊的代码区域。有可能产生违例，并在后面尾随用于控制那些违例的代码。

2.1     t r y 块

若位于一个方法内部，并“掷”出一个违例（或在这种方法内部调用的还有一个方法产生了违例），那个方法就会在违例产生过程中退出。若不想一个throw 离开方法。可在那个方法内部设置一个特殊的代码块。用它捕获违例。

这就叫作“try块”，由于要在这个地方“尝试”各种方法调用。try 块属于一种普通的作用域，用一个try keyword开头：

try {

// 可能产生违例的代码

}

若用一种不支持违例控制的编程语言全面检查错误，必须用设置和错误检測代码将每一个方法都包围起来——即便多次调用同样的方法。而在使用了违例控制技术后，可将全部东西都置入一个try 块内。在同一地点捕获全部违例。这样便可极大简化我们的代码，并使其更易辨读，由于代码本身要达到的目标再也不会与繁复的错误检查混淆。

2.2     违例控制器

当然，生成的违例必须在某个地方中止。这个“地方”便是违例控制器或者违例控制模块。并且针对想捕获的每种违例类型，都必须有一个对应的违例控制器。违例控制器紧接在try 块后面。且用catch（捕获）keyword标记。例如以下所看到的：

try {

// Code that might generateexceptions

} catch(Type1 id1) {

// Handle exceptions of Type1

} catch(Type2 id2) {

// Handle exceptions of Type2

} catch(Type3 id3) {

// Handle exceptions of Type3

}

// etc...

每一个catch 从句——即违例控制器——都类似一个小型方法，它须要採用一个（并且仅仅有一个）特定类型的自变量。可在控制器内部使用标识符（id1，id2 等等），就象一个普通的方法自变量那样。

我们有时也根本不使用标识符，由于违例类型已提供了足够的信息，可有效处理违例。

但即使不用。标识符也必须就位。

控制器必须“紧接”在try 块后面。若“掷”出一个违例，违例控制机制就会搜寻自变量与违例类型相符的第一个控制器。随后，它会进入那个catch 从句，并觉得违例已得到控制（一旦catch 从句结束。对控制器的搜索也会停止）。

仅仅有相符的catch 从句才会得到运行。它与switch 语句不同。后者在每一个case 后都须要一个break 命令。防止误运行其它语句。

在try 块内部，请注意大量不同的方法调用可能生成同样的违例，但仅仅须要一个控制器。

1. 中断与恢复

在违例控制理论中，共存在两种基本方法。在“中断”方法中（Java 和C++提供了对这样的方法的支持）。假定错误很关键，没有办法返回违例发生的地方。

不管谁仅仅要“掷”出一个违例。就表明没有办法补救错误。并且也不希望再回来。

还有一种方法叫作“恢复”。它意味着违例控制器有责任来纠正当前的状况，然后取得出错的方法。假定下一次会成功运行。若使用恢复，意味着在违例得到控制以后仍然想继续运行。

在这样的情况下。我们的违例更象一个方法调用——我们用它在Java 中设置各种各样特殊的环境，产生类似于“恢复”的行为（换言之。此时不是“掷”出一个违例，而是调用一个用于解决这个问题的方法）。另外。也能够将自己的try 块置入一个while 循环里。用它不断进入try 块，直到结果惬意时为止。从历史的角度看，若程序猿使用的操作系统支持可恢复的违例控制。终于都会用到类似于中断的代码。并跳过恢复进程。所以虽然“恢复”表面上十分不错，但在实际应用中却显得困难重重。当中决定性的原因可能是：我们的控制模块必须随时留意是否产生了违例，以及是否包括了由产生位置专用的代码。这便使代码非常难编写和维护——大型系统尤其如此，由于违例可能在多个位置产生。

2.3     违例规范

在Java 中，对那些要调用方法的客户程序猿，我们要通知他们可能从自己的方法里“掷”出违例。这是一种有礼貌的做法，仅仅有它才干使客户程序猿准确地知道要编写什么代码来捕获全部潜在的违例。当然。若你同一时候提供了源代码，客户程序猿甚至能全盘检查代码，找出对应的throw 语句。但虽然如此。通常并不随同源代码提供库。为解决问题，Java 提供了一种特殊的语法格式（并强迫我们採用），以便礼貌地告诉客户程序猿该方法会“掷”出什么违例，令对方方便地加以控制。

这便是我们在这里要讲述的“违例规范”。它属于方法声明的一部分，位于自变量（參数）列表的后面。

违例规范採用了一个额外的keyword：throws。后面尾随所有潜在的违例类型。因此。我们的方法定义看起来应象以下这个样子：

void f() throws tooBig,tooSmall, divZero { //...

若使用下述代码：

void f() [ // ...

它意味着不会从方法里“掷”出违例（除类型为RuntimeException的违例以外，它可能从不论什么地方掷出——稍后还会具体讲述）。

但不能全然依赖违例规范——假若方法造成了一个违例，但没有对其进行控制。编译器会侦測到这个情况，并告诉我们必须控制违例。或者指出应该从方法里“掷”出一个违例规范。

通过坚持从顶部究竟部排列违例规范。Java 可在编译期保证违例的正确性。

这是在C++违例控制基础上一个显著的进步，后者除非到执行期，否则不会捕获不符合违例规范的错误。

这使得C++的违例控制机制显得用处不大。

我们在这个地方可採取欺骗手段：要求“掷”出一个并没有发生的违例。编译器能理解我们的要求，并强迫使用这种方法的用户当作真的产生了那个违例处理。在实际应用中，可将其作为那个违例的一个“占位符”使用。这样一来，以后能够方便地产生实际的违例，毋需改动现有的代码。

2.4     捕获全部违例

我们可创建一个控制器，令其捕获全部类型的违例。详细的做法是捕获基础类违例类型Exception（也存在其它类型的基础违例，但Exception 是适用于差点儿全部编程活动的基础）。例如以下所看到的：

catch(Exception e) {

System.out.println("caughtan exception");

}

这段代码能捕获不论什么违例。所以在实际使用时最好将其置于控制器列表的末尾，防止尾随在后面的不论什么特殊违例控制器失效。

对于程序猿经常使用的全部违例类来说，因为Exception 类是它们的基础。所以我们不会获得关于违例太多的信息，但可调用来自它的基础类Throwable 的方法：

String getMessage()

获得具体的消息。

String toString()

返回对Throwable 的一段简要说明，当中包含具体的消息（假设有的话）。

void printStackTrace()

voidprintStackTrace(PrintStream)

打印出Throwable 和Throwable 的调用堆栈路径。调用堆栈显示出将我们带到违例发生地点的方法调用的顺序。

第一个版本号会打印出标准错误，第二个则打印出我们的选择流程。若在Windows 下工作，就不能重定向标准错误。

因此，我们一般愿意使用第二个版本号。并将结果送给System.out；这样一来。输出就可重定向到我们希望的不论什么路径。

除此以外，我们还可从Throwable 的基础类Object（全部对象的基础类型）获得另外一些方法。对于违例控制来说。当中一个可能实用的是getClass()。它的作用是返回一个对象，用它代表这个对象的类。我们可依次用getName()或toString()查询这个Class 类的名字。亦可对Class 对象进行一些复杂的操作。虽然那些操作在违例控制中是不必要的。

以下展示了Exception 方法的使用

2.4.1       代码

public
class ExceptionMethods {

public
staticvoidmain(String[]
args){

try {

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();

}

}

}/// :~

2.4.2       运行结果

java.lang.Exception: Here's my Exception

at ExceptionMethods.main(ExceptionMethods.java:4)

CaughtException

e.getMessage():Here's my Exception

e.toString():java.lang.Exception: Here's my Exception

e.printStackTrace():

2.5     又一次“掷”出违例

在某些情况下，我们想又一次掷出刚才产生过的违例，特别是在用Exception捕获全部可能的违例时。

因为我们已拥有当前违例的句柄。所以仅仅需简单地又一次掷出那个句柄就可以。

以下是一个样例：

catch(Exception e) {

System.out.println("一个违例已经产生");

throw e;

}

又一次“掷”出一个违例导致违例进入更高一级环境的违例控制器中。用于同一个try 块的不论什么更进一步的catch 从句仍然会被忽略。此外。与违例对象有关的全部东西都会得到保留。所以用于捕获特定违例类型的更高一级的控制器能够从那个对象里提取出全部信息。

若仅仅是简单地又一次掷出当前违例，我们打印出来的、与printStackTrace()内的那个违例有关的信息会与违例的起源地相应，而不是与又一次掷出它的地点相应。

若想安装新的堆栈跟踪信息，可调用fillInStackTrace()。它会返回一个特殊的违例对象。这个违例的创建步骤例如以下：将当前堆栈的信息填充到原来的违例对象里。

2.5.1       代码2

public
class Rethrowing {

public
staticvoidf()
throwsException {

System.out.println("originating the exception in f()");

throw
new Exception("thrown from f()");

}

public
staticvoidg()
throwsThrowable {

try {

f();

} catch (Exception
e) {

System.out.println("Inside g(), e.printStackTrace()");

e.printStackTrace();

throw
e; // 17

// throw e.fillInStackTrace(); // 18

}

}

public
staticvoidmain(String[]
args)throwsThrowable {

try {

g();

} catch (Exception
e) {

System.out.println("Caught in main, e.printStackTrace()");

e.printStackTrace();

}

}

}/// :~

2.5.2       运行结果

originatingthe exception in f()

Insideg(), e.printStackTrace()

Caughtin main, e.printStackTrace()

java.lang.Exception: thrown from f()

at Rethrowing.f(Rethrowing.java:4)

at Rethrowing.g(Rethrowing.java:9)

at Rethrowing.main(Rethrowing.java:20)

java.lang.Exception: thrown from f()

at Rethrowing.f(Rethrowing.java:4)

at Rethrowing.g(Rethrowing.java:9)

at Rethrowing.main(Rethrowing.java:20)

因此，违例堆栈路径不管怎样都会记住它的真正起点，不管自己被反复“掷”了好几次。

若将第17 行标注（变成凝视行），而撤消对第18 行的标注，就会换用fillInStackTrace()。结果例如以下：

originatingthe exception in f()

Insideg(), e.printStackTrace()

java.lang.Exception: thrown from f()

at Rethrowing.f(Rethrowing.java:4)

at Rethrowing.g(Rethrowing.java:9)

at Rethrowing.main(Rethrowing.java:20)

java.lang.Exception: thrown from f()

at Rethrowing.g(Rethrowing.java:14)

at Rethrowing.main(Rethrowing.java:20)

Caughtin main, e.printStackTrace()

因为使用的是fillInStackTrace()，第18 行成为违例的新起点。

针对g()和main()，Throwable 类必须在违例规格中出现，由于fillInStackTrace()会生成一个Throwable对象的句柄。

由于Throwable 是Exception 的一个基础类。所以有可能获得一个可以“掷”出的对象（具有Throwable属性），但却并不是一个Exception（违例）。因此。在main()中用于Exception 的句柄可能丢失自己的目标。为保证全部东西均井然有序。编译器强制Throwable使用一个违例规范。

举个样例来说，下述程序的违例便不会在main()中被捕获到

2.5.3       代码3

public
class ThrowOut {

public
staticvoidmain(String[]
args)throwsThrowable {

try {

throw
new Throwable();

} catch (Exception
e) {

System.out.println("Caught in main()");

}

}

}/// :~

2.5.4       运行结果

Exceptionin thread "main" java.lang.Throwable

at ThrowOut.main(ThrowOut.java:4)

也有可能从一个已经捕获的违例又一次“掷”出一个不同的违例。但假如这样做，会得到与使用

fillInStackTrace()类似的效果：与违例起源地有关的信息会所有丢失，我们留下的是与新的throw 有关的信息。例如以下所看到的：

2.5.5       代码4

public
class RethrowNew {

public
staticvoidf()
throwsException {

System.out.println("originating the exception in f()");

throw
new Exception("thrown from f()");

}

public
staticvoidmain(String[]
args){

try {

f();

} catch (Exception
e) {

System.out.println("Caught in main, e.printStackTrace()");

e.printStackTrace();

throw
new NullPointerException("from main");

}

}

} /// :~

2.5.6       运行结果

originatingthe exception in f()

Caughtin main, e.printStackTrace()

java.lang.Exception: thrown from f()

at RethrowNew.f(RethrowNew.java:4)

at RethrowNew.main(RethrowNew.java:9)

Exceptionin thread "main"
java.lang.NullPointerException: from main

at RethrowNew.main(RethrowNew.java:13)

最后一个违例仅仅知道自己来自main()。而非来自f()。注意Throwable 在不论什么违例规范中都没必要的。永远不必关心怎样清除前一个违例。或者与之有关的其它不论什么违例。它们都属于用new 创建的、以内存堆为基础的对象，所以垃圾收集器会自己主动将其清除。