为什么需要自定义错误类？
在应用程序开发中，错误处理是不可或缺的一部分。javascript提供了内置的error对象及其派生类（如typeerror、referenceerror等）来表示运行时错误。然而，在许多业务场景中，我们可能需要定义特定于应用程序逻辑的错误类型。
考虑以下场景，我们有一个promptDirection函数，它根据用户输入返回方向，如果输入无效，则抛出错误：
class InputError extends Error {} // 自定义InputError
function promptDirection(question) {
let result = prompt(question);
if (result.toLowerCase() == "left") return "L";
if (result.toLowerCase() == "right") return "R";
throw new InputError("Invalid direction: " + result); // 抛出自定义错误
}
for (;;) {
try {
let dir = promptDirection("Where?");
console.log("You chose ", dir);
break;
} catch (e) {
if (e instanceof InputError) { // 精确识别InputError
console.log("Not a valid direction. Try again.");
} else {
throw e; // 重新抛出其他未预期的错误
}
}
}在这个例子中，InputError是一个继承自Error的自定义类。有人可能会问，为什么不直接抛出Error实例，例如throw new Error("Invalid direction: " + result);？
自定义错误类的核心优势
使用自定义错误类而非直接使用Error的主要目的是为了实现精确的错误识别和分类，从而允许更细粒度的错误处理逻辑。
-
基于类型识别错误（instanceof操作符） 当抛出一个InputError实例时，在catch块中，我们可以使用instanceof操作符来判断捕获到的错误e是否为InputError类型：
if (e instanceof InputError) { console.log("Not a valid direction. Try again."); } else { throw e; }如果直接抛出new Error(...)，那么if (e instanceof InputError)将永远不会为真，我们就无法区分这是一个用户输入错误还是其他类型的系统错误。通过instanceof，我们可以清晰地将应用程序特有的错误与通用运行时错误区分开来，并执行不同的恢复策略（例如，提示用户重试而不是直接崩溃）。
立即学习“Java免费学习笔记（深入）”；
构建清晰的错误层级结构 通过继承Error，我们可以构建一个语义化的错误层级结构。例如，可以有一个AppError基类，然后派生出InputError、NetworkError、PermissionError等。这不仅提高了代码的可读性，也使得错误类型一目了然。当错误发生时，开发者可以迅速了解错误的来源和性质。
-
封装特定于错误的信息 自定义错误类可以包含额外的属性和方法，以提供关于错误更详细的上下文信息。例如，InputError可以包含一个input属性来存储导致错误的具体输入值：
class InputError extends Error { constructor(message, invalidInput) { super(message); this.name = "InputError"; // 推荐设置name属性 this.invalidInput = invalidInput; } } // 抛出时： throw new InputError("Invalid direction", result); // 捕获时： if (e instanceof InputError) { console.log(`Not a valid direction. You entered: ${e.invalidInput}. Try again.`); }这使得错误处理逻辑能够访问更多诊断信息，从而做出更智能的决策。
替代方案及其局限性
虽然使用自定义错误类和instanceof是推荐的做法，但也存在其他识别错误的方式，但它们通常不如前者健壮：
- 检查错误消息（e.message）： 可以通过匹配e.message字符串来识别错误。然而，这种方法非常脆弱，因为错误消息的内容可能会在代码重构或国际化时发生变化，导致匹配失败。
- 添加自定义错误代码（e.code）： 可以在Error实例上添加一个自定义的code属性，例如const err = new Error("..."); err.code = "INPUT_INVALID"; throw err;。然后通过e.code === "INPUT_INVALID"来识别。这种方法比检查message更安全，但它没有利用JavaScript的类型系统，且不如instanceof直观和符合面向对象设计原则。它本质上是在模拟类型，但没有真正的类型检查优势。
最佳实践与注意事项
- 继承Error：始终通过class CustomError extends Error {}来创建自定义错误类，以确保它们具有Error对象的所有标准属性（如name、message、stack）。
- 设置name属性：在自定义错误的构造函数中，通常建议设置this.name = "CustomErrorName";，这样在错误被打印或序列化时，其类型会更清晰。
- 明确错误边界：不要为每一个细微的错误都创建自定义类。只为那些需要特定处理逻辑或代表特定业务状态的错误创建自定义类。
- 保持一致性：在整个项目中，统一错误处理策略，例如是使用instanceof还是自定义code，但强烈推荐前者。
- 可序列化性：如果错误需要在网络上传输或存储，请确保自定义错误类及其属性是可序列化的。
总结
通过继承Error类创建自定义错误，是JavaScript中一种强大且推荐的错误处理模式。它使得开发者能够利用instanceof操作符进行精确的错误类型识别，构建清晰的错误层级，并封装错误相关的额外信息。这种方法不仅提高了代码的健壮性和可维护性，也使得应用程序的错误处理逻辑更加语义化和可控，从而提升了整体的用户体验和系统稳定性。
