Java违例控制

梦里梦外; 2022-06-14 11:28 172阅读 0赞

“违例”（Exception）这个词表达的是一种“例外”情况，亦即正常情况之外的一种“异常”。

在问题发生的时候，我们可能不知具体该如何解决，但肯定知道已不能不顾一切地继续下去。此时，必须坚决地停下

来，并由某人、某地指出发生了什么事情，以及该采取何种对策。但为了真正解决问题，当地可能并没有足够多的信息。因此，我们需要将其移交给更级的负责人，令其作出正确的决定（类似一个命令链）。

“违例条件”表示在出现什么问题的时候应中止方法或作用域的继续。为了将违例条件与普通问题区分开，违例条件是非常重要的一个因素。在普通问题的情况下，我们在当地已拥有足够的信息，可在某种程度上解决碰到的问题。而在违例条件的情况下，却无法继续下去，因为当地没有提供解决问题所需的足够多的信息。此时，我们能做的唯一事情就是跳出当地环境，将那个问题委托给一个更高级的负责人。这便是出现违例时出现的情况。

和Java 的其他任何对象一样，需要用new 在内存堆里创建违例，并需调用一个构建器。在所有标准违例中，存在着两个构建器：第一个是默认构建器，第二个则需使用一个字串自变量，使我们能在违例里置入相关信息：  
if(t == null)  
throw new NullPointerException("t = null");

关键字throw 会象变戏法一样做出一系列不可思议的事情。它首先执行new 表达式，创建一个不在程序常规执行范围之内的对象。而且理所当然，会为那个对象调用构建器。随后，对象实际会从方法中返回——尽管对象的类型通常并不是方法设计为返回的类型。为深入理解违例控制，可将其想象成另一种返回机制——但是不要在这个问题上深究，否则会遇到麻烦。通过“掷”出一个违例，亦可从原来的作用域中退出。但是会先返回一个值，再退出方法或作用域。  
但是，与普通方法返回的相似性到此便全部结束了，因为我们返回的地方与从普通方法调用中返回的地方是迥然有异的（我们结束于一个恰当的违例控制器，它距离违例“掷”出的地方可能相当遥远——在调用堆栈中要低上许多级）。

我们可根据需要掷出任何类型的“可掷”对象。典型情况下，我们要为每种不同类型的错误“掷”出一类不同的违例。我们的思路是在违例对象以及挑选的违例对象类型中保存信息，所以在更大场景中的某个人可知道如何对待我们的违例（通常，唯一的信息是违例对象的类型，而违例对象中保存的没什么意义）。

为理解违例是如何捕获的，首先必须掌握“警戒区”的概念。它代表一个特殊的代码区域，有可能产生违例，并在后面跟随用于控制那些违例的代码。若位于一个方法内部，并“掷”出一个违例（或在这个方法内部调用的另一个方法产生了违例），那个方法就会在违例产生过程中退出。若不想一个throw 离开方法，可在那个方法内部设置一个特殊的代码块，用它捕获违例。这就叫作“try 块”，因为要在这个地方“尝试”各种方法调用。try 块属于一种普通的作用域，用一个try 关键字开头：  
try \{  
// 可能产生违例的代码  
\}

生成的违例必须在某个地方中止。这个“地方”便是违例控制器或者违例控制模块。而且针对想捕获的每种违例类型，都必须有一个相应的违例控制器。违例控制器紧接在try 块后面，且用catch（捕获）关键字标记。如下所示：  
try \{  
// Code that might generate exceptions  
\} 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 块内部，请注意大量不同的方法调用可能生成相同的违例，但只需要一个控制器。

在违例控制理论中，共存在两种基本方法。在“中断”方法中（Java 和C++提供了对这种方法的支持），我们假定错误非常关键，没有办法返回违例发生的地方。无论谁只要“掷”出一个违例，就表明没有办法补救错误，而且也不希望再回来。  
另一种方法叫作“恢复”。它意味着违例控制器有责任来纠正当前的状况，然后取得出错的方法，假定下一次会成功执行。若使用恢复，意味着在违例得到控制以后仍然想继续执行。在这种情况下，我们的违例更象一个方法调用——我们用它在Java 中设置各种各样特殊的环境，产生类似于“恢复”的行为（换言之，此时不是“掷”出一个违例，而是调用一个用于解决问题的方法）。另外，也可以将自己的try 块置入一个while 循环里，用它不断进入try 块，直到结果满意时为止。

**创建违例**

我们可创建一个控制器，令其捕获所有类型的违例。具体的做法是捕获基础类违例类型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 对象进行一些复杂的操作，尽管那些操作在违例控制中是不必要的。