24 KiB
八、处理缺陷与错误
程序是开发人员智慧的结晶。而程序中出现的缺陷或错误则是设计本身，或者是在设计转化成程序代码的过程中引入的。
我们通常将程序中的缺陷称为bug。而bug则有可能是开发人员编写的代码导致的，也有可能是程序与其他系统交互时产生的。有些程序中的bug很容易被发现，而有些则会在系统中隐藏很久，难以发现。
通常来说，只有在程序执行的代码逻辑不符合开发人员意图的时候，问题才比较容易被发现。有时这种情况难以避免。当程序要求用户输入年龄的时候，用户却将“橘子”作为输入，我们的程序可能就很难处理这种情况了。我们必须采用某种方法来预备并处理这种情况的发生。
8.1 开发人员造成的问题
当问题出现在开发人员编写的代码中时，我们的目标十分简单，就是找到问题的所在并修复它们。这类问题十分广泛，简单到代码的拼写错误，细微到一些特殊情况下计算机会将代码错误地理解成另一种含义并执行，然后导致错误的发生。而后者往往需要数周的时间才能被发现。
不同的编程语言为开发人员寻找错误提供了不同程度的支持。不幸的是，JavaScript几乎没有为开发人员提供任何帮助。一些语言在执行程序之前需要确定程序中所有变量和表达式的类型，在类型不一致时也会立即向开发者报告。JavaScript只会在实际执行程序时判断类型，即便如此，JavaScript也允许开发人员编写一些明显不对的代码，却不发出任何警告，比如x=true*“monkey”。
虽说如此，JavaScript还是会在遇到某些问题时报告错误。当JavaScript遇到程序中的语法错误时，会立即报告错误。此外，当程序执行到一些明显不对的代码逻辑，比如调用的值根本不是函数，或尝试从undefined中获取属性时，都会引发错误并将错误通知给开发人员。
不过，JavaScript在处理无意义的计算时，会直接返回NaN（表示不是数字）或undefined这样的结果。程序会认为其执行的代码毫无问题并顺利运行下去，要等到随后的运行过程中才会出现问题，而此时已经有许多函数使用了这个无意义的值。程序执行中也可能不会遇到任何错误，只会产生错误的程序输出。找出这类错误的源头是非常困难的。
我们将查找程序中的错误或者bug的过程称为调试（debug）。
8.2 严格模式
当启用了严格模式（strict mode）后，JavaScript就会在执行代码时变得更为严格。我们只需在文件或函数体顶部放置字符串“use strict”就可以启用严格模式了。下面是示例代码：
function canYouSpotTheProblem() {
"use strict";
for (counter = 0; counter < 10; counter++)
console.log("Happy happy");
}
canYouSpotTheProblem();
// → ReferenceError: counter is not defined
当你忘记在变量前添加var时，比如示例中的counter。在默认情况下，JavaScript会悄悄创建一个全局变量，并使用这个全局变量。但在严格模式中这种行为就会引发错误。这种特性非常有用。不过需要注意的是如果代码中已经将该变量定义为全局变量，那么这里就不会发生任何错误，而是直接将值赋予已经创建的全局变量。
严格模式中还有另一个变化，如果我们没有将函数作为方法调用，函数中的this会绑定undefined。而如果没有在严格模式中，函数的this会引用一个全局对象。因此如果你在严格模式中不小心错误调用了一个方法或构造函数，JavaScript会立即报告错误（因为会尝试读取this），而不是创建一个全局对象并读取全局对象。
思考下面的代码，代码中调用构造函数时并未使用关键字new，因此this不会引用新创建的对象。
function Person(name) { this.name = name; }
var ferdinand = Person("Ferdinand"); // oops
console.log(name);
// → Ferdinand
虽然我们错误调用了Person，代码也可以执行成功，但会返回一个未定义值，并创建名为name的全局变量。而在严格模式中，结果就不同了。
"use strict";
function Person(name) { this.name = name; }
// Oops, forgot 'new'
var ferdinand = Person("Ferdinand");
// → TypeError: Cannot set property 'name' of undefined
JavaScript会立即告知我们代码中包含错误。这种特性十分有用。
严格模式还有很多其他特性。该模式下，不允许将多个同名参数赋予函数。完全移除一些本身就有问题的语言特性（比如with语句，该功能太具误导性，因此本书不会对其进行讨论）。
简而言之，在程序顶部放置“use strict”无伤大雅，而且能够帮助你发现问题。
8.3 测试
如果语言本身不能帮助我们找出错误，我们也可以通过运行程序来找出错误，并观察是否能得到我们期望的结果，只不过这种方法不是很好操作。
重复进行手动测试明显会令人抓狂。所幸的是我们可以编写第二个程序来自动测试实际的程序。
作为示例，我们再次使用Vector类型。
function Vector(x, y) {
this.x = x;
this.y = y;
}
Vector.prototype.plus = function(other) {
return new Vector(this.x + other.x, this.y + other.y);
};
我们将会编写一个程序来检查Vector的实现是否符合我们的预期。接着，在每次修改实现时，我们都执行这个测试程序，以确保我们没有破坏原有的代码逻辑。当添加额外功能时（比如添加新的方法），我们也可以为新添加的功能编写测试。
function testVector() {
var p1 = new Vector(10, 20);
var p2 = new Vector(-10, 5);
var p3 = p1.plus(p2);
if (p1.x !== 10) return "fail: x property";
if (p1.y !== 20) return "fail: y property";
if (p2.x !== -10) return "fail: negative x property";
if (p3.x !== 0) return "fail: x from plus";
if (p3.y !== 25) return "fail: y from plus";
return "everything ok";
}
console.log(testVector());
// → everything ok
这样编写测试容易产生重复糟糕的代码。幸运的是有些软件可以帮助你构建并运行测试集（测试套件），并提供了一种适合描述测试的语言（以函数和方法的形式描述），当测试失败时会输出有用的信息。我们将这类软件称为测试框架。
8.4 调试
当程序的运行结果不符合预期或在运行过程中产生错误时，你就会注意到程序出现问题了，下一步就是要推断问题出在什么地方。
有时错误很明显。错误消息会指出错误出现在程序的哪一行，只要稍加阅读错误描述及出错的那行代码，你一般就知道如何修正错误了。
但问题往往不会这么简单。触发问题的代码行有时只不过是第一个非法使用错误值的位置，而那个错误值则是在其他位置产生的。有时甚至没有任何错误消息，只有一个无效结果。如果读者编写了前面章节中的习题，就可能已经非常熟悉这种情况了。
下面的示例代码尝试将一个整数转换成任意进制表示的字符串（十进制、二进制等），其原理是：不断循环取出最后一位数字，并将其除以基数（将最后一位数从数字中除去）。但该程序目前的输出表明程序中是存在bug的。
function numberToString(n, base) {
var result = "", sign = "";
if (n < 0) {
sign = "-";
n = -n;
}
do {
result = String(n % base) + result;
n /= base;
} while (n > 0);
return sign + result;
}
console.log(numberToString(13, 10));
// → 1.5e-3231.3e-3221.3e-3211.3e-3201.3e-3191.3e-3181.3…
你可能已经发现程序运行结果不对了，不过先暂时装作不知道。我们知道程序运行出了问题，试图找出其原因。
我们必须遏制住随意修改代码进行调试的冲动，思考才是最重要的。分析一下程序运行出错的原因，并推测出一个理论。接着，针对这个推测理论再对程序做些观察。抑或你手上还没有一个现实可行的理论，再多做些观察，也许就可以发现一些蛛丝马迹了。
有目的地在程序中使用console.log来查看程序当前的运行状态，是一种不错的获取额外信息的方法。在本例中，我们希望n的值依次变为13、1，然后是0。让我们先在循环起始处输出n的值。
13
1.3
0.13
0.013
…
1.5e-323
没错。13除以10并不会产生整数。我们不应该使用n/=base，而应该使用n=Math.floor（n/base），使数字“右移”，这才是我们实际想要的结果。
另一种替代console.log的方案是使用浏览器的调试器功能。现代浏览器可以在特定代码行上设置断点。这使得程序每次执行到断点所在行时会暂停执行，这样你就可以查看那一刻变量的值。由于不同浏览器之间调试器差异很大，因此笔者不会深入介绍其细节，但读者可以顺便看看浏览器开发者工具，并在网络上搜索更多信息。另一个设置断点的方式是在程序中包含debugger语句（直接使用该关键字即可）。如果浏览器开发者工具处于激活状态，程序遇到该语句后会暂停执行，并在这时查看程序的状态。
8.5 错误传播
不过开发人员不可能避免所有的问题。只要你的程序使用了某种方式与外界进行通信，就有可能会获取到无效的输入，与之通信的其他系统也有可能损坏或无法访问。
对于简单的程序和在你观察下运行的程序来说，我们可以在程序运行出现问题的时候直接停止程序的执行。你可以实时地研究并解决问题，然后重新运行。不过对于真实环境下的应用程序来说，我们不能直接让程序崩溃。有时正确的做法反而是接受错误的输入并继续执行程序。另外，最好在应用程序出现错误的时候通知用户，然后再退出。而还有一些情况，我们需要确保程序在出现错误的时候作出积极响应，并执行一些处理逻辑。
假设有一个函数promptInteger，该函数向用户请求一个整数，并将其返回。如果用户输入orange，程序该如何处理呢？
一种办法是返回一个特殊值，通常会使用null或undefined。
function promptNumber(question) {
var result = Number(prompt(question, ""));
if (isNaN(result)) return null;
else return result;
}
console.log(promptNumber("How many trees do you see?"));
这是一种合理的处理方式。现在任何代码调用promptNumber时，都需要检查读取的值是否是一个实际的数字，如果失败，必须以某种方法恢复程序执行——再次询问输入或使用一个默认值。
在许多情况中，当错误很普遍时，调用方通常应该显式地处理无效的返回值，返回一个特殊值是指出错误的极佳方式。但这种方式也有其不足之处。如果函数本身就可以返回任何类型的值，该如何处理？对于这类函数，我们难以找到一个特殊值，可以区分有效的结果和无效的结果。
返回特殊值还会让代码看起来非常凌乱。如果代码中调用了10次promptNumber，就需要检查10次返回值是否为null。如果当发现null时，处理方式也是简单地返回null，那么函数调用方需要轮流检查特殊值。
8.6 异常
当函数无法正常工作时，我们只希望停止当前任务，并立即跳转回负责处理问题的位置。这就是异常处理的功能。
异常是一种当代码执行中遇到问题时，可以触发（或抛出）异常的机制，异常只是一个普通的值。触发异常类似于从函数中强制返回：异常不只跳出到当前函数中，还会跳出函数调用方，直到当前执行流初次调用函数的位置。这种方式被称为“堆栈展开（Unwinding the Stack）”。你可能还记得我们在第3章中介绍的函数调用栈，异常会减小堆栈的尺寸，并丢弃所有在缩减程序栈尺寸过程中遇到的函数调用上下文。
如果异常总是会将堆栈尺寸缩减到栈底，那么异常也就毫无用处了。它只不过是换了一种方式来彻底破坏你的程序罢了。异常真正强大的地方在于你可以在堆栈上设置一个“障碍物”，当异常缩减堆栈到达这个位置时会被捕获。接着你就可以对异常进行一些处理，并使得程序从异常捕获点开始继续执行。这里给出一个示例。
function promptDirection(question) {
var result = prompt(question, "");
if (result.toLowerCase() == "left") return "L";
if (result.toLowerCase() == "right") return "R";
throw new Error("Invalid direction: " + result);
}
function look() {
if (promptDirection("Which way?") == "L")
return "a house";
else
return "two angry bears";
}
try {
console.log("You see", look());
} catch (error) {
console.log("Something went wrong: " + error);
}
throw关键字用于触发异常。将throw语句填写在try块中，紧跟catch关键字，就可以捕获代码片段中的异常。当try块中的代码引发异常，程序就会执行catch块。catch关键字后的变量名（在括号中）会绑定到异常值。如果在catch块结束或try块正常结束后，未引发任何问题，那么控制流将会跳转到try/catch语句下方。
在本例中，我们使用Error构造函数来创建异常值。这是一个标准的JavaScript构造函数，用于创建一个对象，包含message属性。在现代JavaScript环境中，构造函数实例也会收集异常创建时的调用栈信息，即堆栈跟踪信息（Stack Trace）。该信息存储在stack属性中，对于调用问题有很大的帮助，我们可以从堆栈跟踪信息中得知问题发生的精确位置，即问题具体出现在哪个函数中，以及执行失败为止调用的其他函数链。
需要注意的是现在look函数可以完全忽略promptDirection出错的可能性。这就是使用异常的优势：只有在错误触发且必须处理的位置才需要错误处理代码。其间的函数可以忽略异常处理。
嗯，我们要讲解的理论知识差不多就这些了。
8.7 异常后清理
考虑下面一种情况：withContext函数执行过程中，会赋予全局变量context一个特殊值。需要确保执行完成后将变量还原为其原始值。
var context = null;
function withContext(newContext, body) {
var oldContext = context;
context = newContext;
var result = body();
context = oldContext;
return result;
}
如果body引发异常会出现什么状况呢？在这种情况下，withContext调用会因异常而丢弃堆栈，context值也无法得到还原。
try语句还有另一项功能，它不仅可以附加catch语句块，还可以追加finally语句块。finally语句块的意思是：无论发生什么，执行完try块中的代码之后，这部分代码都必须执行。如果函数不得不完成一些清理任务，那么清理代码通常应该放置在finally块中。
function withContext(newContext, body) {
var oldContext = context;
context = newContext;
try {
return body();
} finally {
context = oldContext;
}
}
我们再也不需要将body结果（希望返回的值）存储在变量中了。即使我们从try块直接返回，finally块也必然会执行。现在我们可以安全完成任务：
try {
withContext(5, function() {
if (context < 10)
throw new Error("Not enough context!");
});
} catch (e) {
console.log("Ignoring: " + e);
}
// → Ignoring: Error: Not enough context!
console.log(context);
// → null
即使withContext中的函数调用引发异常，witchContext自身依然可以正确清理context变量。
8.8 选择性捕获
当程序出现异常且异常未被捕获时，异常就会直接回退到栈顶，并由JavaScript环境来处理。其处理方式会根据环境的不同而不同。在浏览器中，错误描述通常会写入JavaScript控制台中（可以使用浏览器工具或开发者菜单来访问控制台）。
如果程序无法处理开发人员编写的错误或问题，我们可以让错误直接传递到环境中去。未处理的异常是一种很好的传递程序奔溃信息的方式，现代浏览器中的JavaScript控制台会在遇到问题时向开发者提供一些函数调用栈信息。
但对于已知的程序运行错误来说，如果我们还去使用未处理异常的方式进行处理，这种方式就不大友好了。
语言的非法使用方式，比如引用一个不存在的变量在null中查询属性或调用的对象不是函数最终都会引发异常。你可以像自己的异常一样捕获这些异常。
进入catch语句块时，我们只知道try体中引发了异常，但不知道引发了哪一类或哪一个异常。
JavaScript（很明显的疏漏）并未对选择性捕获异常提供良好的支持，要不捕获所有异常，要不什么都不捕获。因此当你编写catch块时，你可以直接假定获得的异常就是你需要处理的那个异常。
但实际情况可能并非如此。这么做可能会影响其他判断逻辑，或者会在新代码中引入一个bug。这里给出一个示例，尝试不断调用promptDirection直到获取到有效的输入为止。
for (;;) {
try {
var dir = promtDirection("Where?"); // ← typo!
console.log("You chose ", dir);
break;
} catch (e) {
console.log("Not a valid direction. Try again.");
}
}
我们可以使用for（；；）循环体来创建一个无限循环，其自身永远不会停止运行。我们在用户给出有效的方向之后会跳出循环。但我们拼写错了promptDirection，因此会引发一个“未定义值”错误。由于catch块完全忽略了异常值，假定其知道问题所在，错将变量错误信息当成错误输入。这样不仅会引发无限循环，而且会掩盖掉真正的错误消息——变量名拼写错误。
一般而言，只有将抛出的异常重定位到其他地方进行处理时，我们才会捕获所有异常。比如说通过网络传输通知其他系统当前应用程序的崩溃信息。即便如此，我们也要注意编写的代码是否会将错误信息掩盖起来。
因此，我们转而会去捕获那些特殊类型的异常。我们可以在catch代码块中判断捕获到的异常是否就是我们期望处理的异常，如果不是则将其重新抛出。那么我们该如何辨别抛出异常的类型呢？
我们当然可以拿抛出异常的message属性与我们期望的错误消息进行比对。但这种做法看起来不大可靠，因为我们编写的代码使用了供人类阅读的信息来进行逻辑判断。如果有人修改（或翻译）了消息中的内容，那么代码就无法正常运行了。
我们不如定义一个新的错误类型，并使用instanceof来识别异常。
function InputError(message) {
this.message = message;
this.stack = (new Error()).stack;
}
InputError.prototype = Object.create(Error.prototype);
InputError.prototype.name = "InputError";
该类型原型继承自Error.prototype，因此所以用instanceof Error来判断InputError类型会返回true。我们也赋予InputError对象一个name属性，因为标准错误类型（如Eroor、SytaxError、ReferenceError等）也有这么一个属性。
我们对stack属性进行赋值，是希望通过该对象提供一些有用的堆栈轨迹信息。在支持堆栈轨迹的平台中，我们只需要创建一个普通的Error对象，并使用该对象的stack属性即可。
现在promptDirection就可以抛出这种类型的错误了。
function promptDirection(question) {
var result = prompt(question, "");
if (result.toLowerCase() == "left") return "L";
if (result.toLowerCase() == "right") return "R";
throw new InputError("Invalid direction: " + result);
}
此时，循环体中的代码可以更加精确地捕获异常了。
for (;;) {
try {
var dir = promptDirection("Where?");
console.log("You chose ", dir);
break;
} catch (e) {
if (e instanceof InputError)
console.log("Not a valid direction. Try again.");
else
throw e;
}
}
这里的catch代码只会捕获InputError类型的异常，而其他类型的异常则不会在这里进行处理。如果又输入了不正确的值，那么系统会向用户准确报告错误——“变量未定义”。
8.9 断言
断言是检查开发人员逻辑错误的基本工具。来看一下这个工具函数assert。
function AssertionFailed(message) {
this.message = message;
}
AssertionFailed.prototype = Object.create(Error.prototype);
function assert(test, message) {
if (!test)
throw new AssertionFailed(message);
}
function lastElement(array) {
assert(array.length > 0, "empty array in lastElement");
return array[array.length - 1];
}
该函数的用法非常简单，我们只需填入期望的结果即可。如果其结果与我们填写的期望不符，程序就会中止运行。比如lastElement函数，该函数会获取数组中的最后一个元素，如果数组为空，而且我们没有在代码中添加断言，那么该函数会返回undefined。但是从一个空数组中获取最后一个元素的操作是无用功，所以这很有可能就是开发人员编写代码时造成的错误。
断言能够确保错误发生时触发程序中止运行的操作，而不是让程序悄悄产生一个无意义的值，然后继续执行下去，直到系统出现其他莫名其妙的错误为止。
8.10 本章小结
错误和无效的输入十分常见。开发人员需要发现并修复程序中的bug。通过自动测试并在程序中添加断言，可以更轻松地发现程序中存在的隐患。
我们常常需要使用优雅的方式来处理程序可控范围外的问题。如果问题可以就地解决，那么返回一个特殊的值来跟踪错误就是一个不错的解决方案。如果你不想用这种方式来跟踪错误，使用异常也行。
抛出异常会引发堆栈展开，直到遇到下一个封闭的try/catch块，或堆栈底部为止。catch块捕获异常后，会将异常值赋予catch块，catch块中应该验证异常是否是实际希望处理的异常，然后进行处理。为了处理由于异常引起的不可预测的执行流，可以使用finally块来确保执行try块之后的代码。
8.11 习题
8.11.1 重试
假设有一个函数primitiveMultiply，在50%的情况下将两个数相乘，在另外50%的情况下会触发MultiplicatorUnitFailure类型的异常。编写一个函数，调用这个容易出错的函数，不断尝试直到调用成功并返回结果为止。
确保只处理你期望的异常。
function MultiplicatorUnitFailure() {}
function primitiveMultiply(a, b) {
if (Math.random() < 0.5)
return a * b;
else
throw new MultiplicatorUnitFailure();
}
function reliableMultiply(a, b) {
// Your code here.
}
console.log(reliableMultiply(8, 8));
// → 64
8.11.2 上锁的箱子
考虑以下这个编写好的对象：
var box = {
locked: true,
unlock: function() { this.locked = false; },
lock: function() { this.locked = true; },
_content: [],
get content() {
if (this.locked) throw new Error("Locked!");
return this._content;
}
};
这是一个带锁的箱子。其中存放了一个数组，但只有在箱子被解锁时，才可以访问数组。不允许直接访问_content属性。
编写一个名为withBoxUnlocked的函数，接受一个函数类型的参数，其作用是解锁箱子，执行该函数，无论是正常返回还是抛出异常，在withBoxUnlocked函数返回前都必须锁上箱子。
function withBoxUnlocked(body) {
// Your code here.
}
withBoxUnlocked(function() {
box.content.push("gold piece");
});
try {
withBoxUnlocked(function() {
throw new Error("Pirates on the horizon! Abort!");
});
} catch (e) {
console.log("Error raised:", e);
}
console.log(box.locked);
// → true