9.1~2

9.1 基本违例.md

@@ -4,9 +4,9 @@
 
 一个简单的例子是“除法”。如可能被零除，就有必要进行检查，确保程序不会冒进，并在那种情况下执行除法。但具体通过什么知道分母是零呢？在那个特定的方法里，在我们试图解决的那个问题的环境中，我们或许知道该如何对待一个零分母。但假如它是一个没有预料到的值，就不能对其进行处理，所以必须产生一个异常，而非不顾一切地继续执行下去。
 
-产生一个异常时，会发生几件事情。首先，按照与创建Java对象一样的方法创建异常对象：在内存“堆”里，使用new来创建。随后，停止当前执行路径（记住不可沿这条路径继续下去），然后从当前的环境中释放出异常对象的引用。此时，异常控制机制会接管一切，并开始查找一个恰当的地方，用于继续程序的执行。这个恰当的地方便是“异常控制器”，它的职责是从问题中恢复，使程序要么尝试另一条执行路径，要么简单地继续。
+产生一个异常时，会发生几件事情。首先，按照与创建Java对象一样的方法创建异常对象：在内存“堆”里，使用`new`来创建。随后，停止当前执行路径（记住不可沿这条路径继续下去），然后从当前的环境中释放出异常对象的引用。此时，异常控制机制会接管一切，并开始查找一个恰当的地方，用于继续程序的执行。这个恰当的地方便是“异常控制器”，它的职责是从问题中恢复，使程序要么尝试另一条执行路径，要么简单地继续。
 
-作为产生异常的一个简单示例，大家可思考一个名为t的对象引用。有些时候，程序可能传递一个尚未初始化的引用。所以在用那个对象引用调用一个方法之前，最好进行一番检查。可将与错误有关的信息发送到一个更大的场景中，方法是创建一个特殊的对象，用它代表我们的信息，并将其“抛”（Throw）出我们当前的场景之外。这就叫作“产生一个异常”或者“抛出一个异常”。下面是它的大概形式：
+作为产生异常的一个简单示例，大家可思考一个名为`t`的对象引用。有些时候，程序可能传递一个尚未初始化的引用。所以在用那个对象引用调用一个方法之前，最好进行一番检查。可将与错误有关的信息发送到一个更大的场景中，方法是创建一个特殊的对象，用它代表我们的信息，并将其“抛”（Throw）出我们当前的场景之外。这就叫作“产生一个异常”或者“抛出一个异常”。下面是它的大概形式：
 
 ```
 if(t == null)
@@ -17,7 +17,7 @@ throw new NullPointerException();
 
 9.1.1 异常参数
 
-和Java的其他任何对象一样，需要用new在内存堆里创建异常，并需调用一个构造器。在所有标准异常中，存在着两个构造器：第一个是默认构造器，第二个则需使用一个字符串参数，使我们能在异常里置入相关信息：
+和Java的其他任何对象一样，需要用`new`在内存堆里创建异常，并需调用一个构造器。在所有标准异常中，存在着两个构造器：第一个是默认构造器，第二个则需使用一个字符串参数，使我们能在异常里置入相关信息：
 
 ```
 if(t == null)
@@ -26,7 +26,7 @@ throw new NullPointerException("t = null");
 
 稍后，字符串可用各种方法提取出来，就象稍后会展示的那样。
 
-在这儿，关键字throw会象变戏法一样做出一系列不可思议的事情。它首先执行new表达式，创建一个不在程序常规执行范围之内的对象。而且理所当然，会为那个对象调用构造器。随后，对象实际会从方法中返回——尽管对象的类型通常并不是方法设计为返回的类型。为深入理解异常控制，可将其想象成另一种返回机制——但是不要在这个问题上深究，否则会遇到麻烦。通过“抛”出一个异常，亦可从原来的作用域中退出。但是会先返回一个值，再退出方法或作用域。
+在这儿，关键字`throw`会象变戏法一样做出一系列不可思议的事情。它首先执行`new`表达式，创建一个不在程序常规执行范围之内的对象。而且理所当然，会为那个对象调用构造器。随后，对象实际会从方法中返回——尽管对象的类型通常并不是方法设计为返回的类型。为深入理解异常控制，可将其想象成另一种返回机制——但是不要在这个问题上深究，否则会遇到麻烦。通过“抛”出一个异常，亦可从原来的作用域中退出。但是会先返回一个值，再退出方法或作用域。
 
 但是，与普通方法返回的相似性到此便全部结束了，因为我们返回的地方与从普通方法调用中返回的地方是迥然有异的（我们结束于一个恰当的异常控制器，它距离异常“抛”出的地方可能相当遥远——在调用栈中要低上许多级）。
 

9.2 违例的捕获.md

@@ -4,9 +4,9 @@
 
 为理解异常是如何捕获的，首先必须掌握“警戒区”的概念。它代表一个特殊的代码区域，有可能产生异常，并在后面跟随用于控制那些异常的代码。
 
-9.2.1 try块
+9.2.1 `try`块
 
-若位于一个方法内部，并“抛”出一个异常（或在这个方法内部调用的另一个方法产生了异常），那个方法就会在异常产生过程中退出。若不想一个throw离开方法，可在那个方法内部设置一个特殊的代码块，用它捕获异常。这就叫作“try块”，因为要在这个地方“尝试”各种方法调用。try块属于一种普通的作用域，用一个try关键字开头：
+若位于一个方法内部，并“抛”出一个异常（或在这个方法内部调用的另一个方法产生了异常），那个方法就会在异常产生过程中退出。若不想一个`throw`离开方法，可在那个方法内部设置一个特殊的代码块，用它捕获异常。这就叫作“`try`块”，因为要在这个地方“尝试”各种方法调用。`try`块属于一种普通的作用域，用一个`try`关键字开头：
 
 ```
 try {
@@ -14,11 +14,11 @@ try {
 }
 ```
 
-若用一种不支持异常控制的编程语言全面检查错误，必须用设置和错误检测代码将每个方法都包围起来——即便多次调用相同的方法。而在使用了异常控制技术后，可将所有东西都置入一个try块内，在同一地点捕获所有异常。这样便可极大简化我们的代码，并使其更易辨读，因为代码本身要达到的目标再也不会与繁复的错误检查混淆。
+若用一种不支持异常控制的编程语言全面检查错误，必须用设置和错误检测代码将每个方法都包围起来——即便多次调用相同的方法。而在使用了异常控制技术后，可将所有东西都置入一个`try`块内，在同一地点捕获所有异常。这样便可极大简化我们的代码，并使其更易辨读，因为代码本身要达到的目标再也不会与繁复的错误检查混淆。
 
 9.2.2 异常控制器
 
-当然，生成的异常必须在某个地方中止。这个“地方”便是异常控制器或者异常控制模块。而且针对想捕获的每种异常类型，都必须有一个相应的异常控制器。异常控制器紧接在try块后面，且用catch（捕获）关键字标记。如下所示：
+当然，生成的异常必须在某个地方中止。这个“地方”便是异常控制器或者异常控制模块。而且针对想捕获的每种异常类型，都必须有一个相应的异常控制器。异常控制器紧接在`try`块后面，且用`catch`（捕获）关键字标记。如下所示：
 
 ```
 try {
@@ -34,24 +34,24 @@ try {
 // etc...
 ```
 
-每个catch从句——即异常控制器——都类似一个小型方法，它需要采用一个（而且只有一个）特定类型的参数。可在控制器内部使用标识符（id1，id2等等），就象一个普通的方法参数那样。我们有时也根本不使用标识符，因为异常类型已提供了足够的信息，可有效处理异常。但即使不用，标识符也必须就位。
+每个`catch`从句——即异常控制器——都类似一个小型方法，它需要采用一个（而且只有一个）特定类型的参数。可在控制器内部使用标识符（`id1`，`id2`等等），就象一个普通的方法参数那样。我们有时也根本不使用标识符，因为异常类型已提供了足够的信息，可有效处理异常。但即使不用，标识符也必须就位。
 
-控制器必须“紧接”在try块后面。若“抛”出一个异常，异常控制机制就会搜寻参数与异常类型相符的第一个控制器。随后，它会进入那个catch从句，并认为异常已得到控制（一旦catch从句结束，对控制器的搜索也会停止）。只有相符的catch从句才会得到执行；它与switch语句不同，后者在每个case后都需要一个break命令，防止误执行其他语句。
-在try块内部，请注意大量不同的方法调用可能生成相同的异常，但只需要一个控制器。
+控制器必须“紧接”在try块后面。若“抛”出一个异常，异常控制机制就会搜寻参数与异常类型相符的第一个控制器。随后，它会进入那个`catch`从句，并认为异常已得到控制（一旦`catch`从句结束，对控制器的搜索也会停止）。只有相符的`catch`从句才会得到执行；它与`switch`语句不同，后者在每个`case`后都需要一个`break`命令，防止误执行其他语句。
+在`try`块内部，请注意大量不同的方法调用可能生成相同的异常，但只需要一个控制器。
 
 1. 中断与恢复
 
 在异常控制理论中，共存在两种基本方法。在“中断”方法中（Java和C++提供了对这种方法的支持），我们假定错误非常关键，没有办法返回异常发生的地方。无论谁只要“抛”出一个异常，就表明没有办法补救错误，而且也不希望再回来。
 
-另一种方法叫作“恢复”。它意味着异常控制器有责任来纠正当前的状况，然后取得出错的方法，假定下一次会成功执行。若使用恢复，意味着在异常得到控制以后仍然想继续执行。在这种情况下，我们的异常更象一个方法调用——我们用它在Java中设置各种各样特殊的环境，产生类似于“恢复”的行为（换言之，此时不是“抛”出一个异常，而是调用一个用于解决问题的方法）。另外，也可以将自己的try块置入一个while循环里，用它不断进入try块，直到结果满意时为止。
+另一种方法叫作“恢复”。它意味着异常控制器有责任来纠正当前的状况，然后取得出错的方法，假定下一次会成功执行。若使用恢复，意味着在异常得到控制以后仍然想继续执行。在这种情况下，我们的异常更象一个方法调用——我们用它在Java中设置各种各样特殊的环境，产生类似于“恢复”的行为（换言之，此时不是“抛”出一个异常，而是调用一个用于解决问题的方法）。另外，也可以将自己的`try`块置入一个`while`循环里，用它不断进入`try`块，直到结果满意时为止。
 
 从历史的角度看，若程序员使用的操作系统支持可恢复的异常控制，最终都会用到类似于中断的代码，并跳过恢复进程。所以尽管“恢复”表面上十分不错，但在实际应用中却显得困难重重。其中决定性的原因可能是：我们的控制模块必须随时留意是否产生了异常，以及是否包含了由产生位置专用的代码。这便使代码很难编写和维护——大型系统尤其如此，因为异常可能在多个位置产生。
 
 9.2.3 异常规范
 
-在Java中，对那些要调用方法的客户程序员，我们要通知他们可能从自己的方法里“抛”出异常。这是一种有礼貌的做法，只有它才能使客户程序员准确地知道要编写什么代码来捕获所有潜在的异常。当然，若你同时提供了源码，客户程序员甚至能全盘检查代码，找出相应的throw语句。但尽管如此，通常并不随同源码提供库。为解决这个问题，Java提供了一种特殊的语法格式（并强迫我们采用），以便礼貌地告诉客户程序员该方法会“抛”出什么异常，令对方方便地加以控制。这便是我们在这里要讲述的“异常规范”，它属于方法声明的一部分，位于参数列表的后面。
+在Java中，对那些要调用方法的客户程序员，我们要通知他们可能从自己的方法里“抛”出异常。这是一种有礼貌的做法，只有它才能使客户程序员准确地知道要编写什么代码来捕获所有潜在的异常。当然，若你同时提供了源码，客户程序员甚至能全盘检查代码，找出相应的`throw`语句。但尽管如此，通常并不随同源码提供库。为解决这个问题，Java提供了一种特殊的语法格式（并强迫我们采用），以便礼貌地告诉客户程序员该方法会“抛”出什么异常，令对方方便地加以控制。这便是我们在这里要讲述的“异常规范”，它属于方法声明的一部分，位于参数列表的后面。
 
-异常规范采用了一个额外的关键字：throws；后面跟随全部潜在的异常类型。因此，我们的方法定义看起来应象下面这个样子：
+异常规范采用了一个额外的关键字：`throws`；后面跟随全部潜在的异常类型。因此，我们的方法定义看起来应象下面这个样子：
 
 ```
 void f() throws tooBig, tooSmall, divZero { //...
@@ -63,7 +63,7 @@ void f() throws tooBig, tooSmall, divZero { //...
 void f() [ // ...
 ```
 
-它意味着不会从方法里“抛”出异常（除类型为RuntimeException的异常以外，它可能从任何地方抛出——稍后还会详细讲述）。
+它意味着不会从方法里“抛”出异常（除类型为`RuntimeException`的异常以外，它可能从任何地方抛出——稍后还会详细讲述）。
 但不能完全依赖异常规范——假若方法造成了一个异常，但没有对其进行控制，编译器会侦测到这个情况，并告诉我们必须控制异常，或者指出应该从方法里“抛”出一个异常规范。通过坚持从顶部到底部排列异常规范，Java可在编译期保证异常的正确性（注释②）。
 
 ②：这是在C++异常控制基础上一个显著的进步，后者除非到运行期，否则不会捕获不符合异常规范的错误。这使得C++的异常控制机制显得用处不大。
@@ -72,7 +72,7 @@ void f() [ // ...
 
 9.2.4 捕获所有异常
 
-我们可创建一个控制器，令其捕获所有类型的异常。具体的做法是捕获基础类异常类型Exception（也存在其他类型的基础异常，但Exception是适用于几乎所有编程活动的基础）。如下所示：
+我们可创建一个控制器，令其捕获所有类型的异常。具体的做法是捕获基础类异常类型`Exception`（也存在其他类型的基础异常，但`Exception`是适用于几乎所有编程活动的基础）。如下所示：
 
 ```
 catch(Exception e) {
@@ -81,7 +81,7 @@ System.out.println("caught an exception");
 ```
 
 这段代码能捕获任何异常，所以在实际使用时最好将其置于控制器列表的末尾，防止跟随在后面的任何特殊异常控制器失效。
-对于程序员常用的所有异常类来说，由于Exception类是它们的基础，所以我们不会获得关于异常太多的信息，但可调用来自它的基础类Throwable的方法：
+对于程序员常用的所有异常类来说，由于`Exception`类是它们的基础，所以我们不会获得关于异常太多的信息，但可调用来自它的基础类`Throwable`的方法：
 
 ```
 String getMessage()
@@ -93,20 +93,20 @@ String getMessage()
 String toString()
 ```
 
-返回对Throwable的一段简要说明，其中包括详细的消息（如果有的话）。
+返回对`Throwable`的一段简要说明，其中包括详细的消息（如果有的话）。
 
 ```
 void printStackTrace()
 void printStackTrace(PrintStream)
 ```
 
-打印出Throwable和Throwable的调用栈路径。调用栈显示出将我们带到异常发生地点的方法调用的顺序。
+打印出`Throwable`和`Throwable`的调用栈路径。调用栈显示出将我们带到异常发生地点的方法调用的顺序。
 
-第一个版本会打印出标准错误，第二个则打印出我们的选择流程。若在Windows下工作，就不能重定向标准错误。因此，我们一般愿意使用第二个版本，并将结果送给System.out；这样一来，输出就可重定向到我们希望的任何路径。
+第一个版本会打印出标准错误，第二个则打印出我们的选择流程。若在Windows下工作，就不能重定向标准错误。因此，我们一般愿意使用第二个版本，并将结果送给`System.out`；这样一来，输出就可重定向到我们希望的任何路径。
 
-除此以外，我们还可从Throwable的基础类Object（所有对象的基础类型）获得另外一些方法。对于异常控制来说，其中一个可能有用的是getClass()，它的作用是返回一个对象，用它代表这个对象的类。我们可依次用getName()或toString()查询这个Class类的名字。亦可对Class对象进行一些复杂的操作，尽管那些操作在异常控制中是不必要的。本章稍后还会详细讲述Class对象。
+除此以外，我们还可从`Throwable`的基础类`Object`（所有对象的基础类型）获得另外一些方法。对于异常控制来说，其中一个可能有用的是`getClass()`，它的作用是返回一个对象，用它代表这个对象的类。我们可依次用`getName()`或`toString()`查询这个`Class`类的名字。亦可对`Class`对象进行一些复杂的操作，尽管那些操作在异常控制中是不必要的。本章稍后还会详细讲述`Class`对象。
 
-下面是一个特殊的例子，它展示了Exception方法的使用（若执行该程序遇到困难，请参考第3章3.1.2小节“赋值”）：
+下面是一个特殊的例子，它展示了`Exception`方法的使用（若执行该程序遇到困难，请参考第3章3.1.2小节“赋值”）：
 
 ```
 //: ExceptionMethods.java
@@ -145,7 +145,7 @@ java.lang.Exception: Here's my Exception
 
 9.2.5 重新“抛”出异常
 
-在某些情况下，我们想重新抛出刚才产生过的异常，特别是在用Exception捕获所有可能的异常时。由于我们已拥有当前异常的引用，所以只需简单地重新抛出那个引用即可。下面是一个例子：
+在某些情况下，我们想重新抛出刚才产生过的异常，特别是在用`Exception`捕获所有可能的异常时。由于我们已拥有当前异常的引用，所以只需简单地重新抛出那个引用即可。下面是一个例子：
 
 ```
 catch(Exception e) {
@@ -154,8 +154,8 @@ throw e;
 }
 ```
 
-重新“抛”出一个异常导致异常进入更高一级环境的异常控制器中。用于同一个try块的任何更进一步的catch从句仍然会被忽略。此外，与异常对象有关的所有东西都会得到保留，所以用于捕获特定异常类型的更高一级的控制器可以从那个对象里提取出所有信息。
-若只是简单地重新抛出当前异常，我们打印出来的、与printStackTrace()内的那个异常有关的信息会与异常的起源地对应，而不是与重新抛出它的地点对应。若想安装新的栈跟踪信息，可调用fillInStackTrace()，它会返回一个特殊的异常对象。这个异常的创建过程如下：将当前栈的信息填充到原来的异常对象里。下面列出它的形式：
+重新“抛”出一个异常导致异常进入更高一级环境的异常控制器中。用于同一个`try`块的任何更进一步的`catch`从句仍然会被忽略。此外，与异常对象有关的所有东西都会得到保留，所以用于捕获特定异常类型的更高一级的控制器可以从那个对象里提取出所有信息。
+若只是简单地重新抛出当前异常，我们打印出来的、与`printStackTrace()`内的那个异常有关的信息会与异常的起源地对应，而不是与重新抛出它的地点对应。若想安装新的栈跟踪信息，可调用`fillInStackTrace()`，它会返回一个特殊的异常对象。这个异常的创建过程如下：将当前栈的信息填充到原来的异常对象里。下面列出它的形式：
 
 ```
 //: Rethrowing.java
@@ -208,7 +208,7 @@ java.lang.Exception: thrown from f()
 ```
 
 因此，异常栈路径无论如何都会记住它的真正起点，无论自己被重复“抛”了好几次。
-若将第17行标注（变成注释行），而撤消对第18行的标注，就会换用fillInStackTrace()，结果如下：
+若将第17行标注（变成注释行），而撤消对第18行的标注，就会换用`fillInStackTrace()`，结果如下：
 
 ```
 originating the exception in f()
@@ -223,9 +223,9 @@ java.lang.Exception: thrown from f()
         at Rethrowing.main(Rethrowing.java:24)
 ```
 
-由于使用的是fillInStackTrace()，第18行成为异常的新起点。
+由于使用的是`fillInStackTrace()`，第18行成为异常的新起点。
 
-针对g()和main()，Throwable类必须在异常规格中出现，因为fillInStackTrace()会生成一个Throwable对象的引用。由于Throwable是Exception的一个基础类，所以有可能获得一个能够“抛”出的对象（具有Throwable属性），但却并非一个Exception（异常）。因此，在main()中用于Exception的引用可能丢失自己的目标。为保证所有东西均井然有序，编译器强制Throwable使用一个异常规范。举个例子来说，下述程序的异常便不会在main()中被捕获到：
+针对`g()`和`main()`，`Throwable`类必须在异常规格中出现，因为`fillInStackTrace()`会生成一个`Throwable`对象的引用。由于`Throwable`是`Exception`的一个基础类，所以有可能获得一个能够“抛”出的对象（具有`Throwable`属性），但却并非一个`Exception`（异常）。因此，在`main()`中用于`Exception`的引用可能丢失自己的目标。为保证所有东西均井然有序，编译器强制`Throwable`使用一个异常规范。举个例子来说，下述程序的异常便不会在`main()`中被捕获到：
 
 ```
 //: ThrowOut.java
@@ -233,7 +233,7 @@ public class ThrowOut {
   public static void
   main(String[] args) throws Throwable {
     try {
-      throw new Throwable(); 
+      throw new Throwable();
     } catch(Exception e) {
       System.out.println("Caught in main()");
     }
@@ -241,7 +241,7 @@ public class ThrowOut {
 } ///:~
 ```
 
-也有可能从一个已经捕获的异常重新“抛”出一个不同的异常。但假如这样做，会得到与使用fillInStackTrace()类似的效果：与异常起源地有关的信息会全部丢失，我们留下的是与新的throw有关的信息。如下所示：
+也有可能从一个已经捕获的异常重新“抛”出一个不同的异常。但假如这样做，会得到与使用`fillInStackTrace()`类似的效果：与异常起源地有关的信息会全部丢失，我们留下的是与新的`throw`有关的信息。如下所示：
 
 ```
 //: RethrowNew.java
@@ -279,6 +279,6 @@ java.lang.NullPointerException: from main
         at RethrowNew.main(RethrowNew.java:18)
 ```
 
-最后一个异常只知道自己来自main()，而非来自f()。注意Throwable在任何异常规范中都不是必需的。
+最后一个异常只知道自己来自`main()`，而非来自`f()`。注意`Throwable`在任何异常规范中都不是必需的。
 
-永远不必关心如何清除前一个异常，或者与之有关的其他任何异常。它们都属于用new创建的、以内存堆为基础的对象，所以垃圾收集器会自动将其清除。
+永远不必关心如何清除前一个异常，或者与之有关的其他任何异常。它们都属于用`new`创建的、以内存堆为基础的对象，所以垃圾收集器会自动将其清除。