何时以及为什么创建自定义异常是好的？

Question

我正在开发一个具有不同类型错误、服务和域概念的复杂应用程序。

为了抛出“对象”错误，我想到了两种不同的方法：

1. 将Object.assign() 应用于一个错误对象（如果我只需要在此表单后面抛出一个或几个错误，这是一个简单的选择）：

function f() {
  const err = new Error();

  Object.assign(err, {
    name: "ServiceError",
    code: "service/some-string-code",
    message: "Some message",
  });

  throw err;
}

try {
  f();
} catch(err) {
  console.log(err instanceof Error);
}

1. 创建自定义错误（扩展 Error 类）

class MyServiceError extends Error {
  constructor(code, message) {
    super(message);
  
    this.name = "ServiceError";
    this.code = code;
  }
}

function f() {
  const err = new MyServiceError("service/some-string-code", "Some message");

  throw err;
}

try {
  f();
} catch(err) {
  console.log(err instanceof Error);
  console.log(err instanceof MyServiceError);
}

这两种“自定义错误定义”的优缺点是什么。

另外，如果我选择第二种方法，我似乎需要为不同的领域概念、服务等创建多个CustomError 类，以实现对称代码和干净的架构......（？ ??) 我认为这反过来又是在重新发明轮子并添加不必要的代码，因为也许并非应用程序的所有概念都需要自定义类型的异常。

这两种做法在 JavaScript 中都被认为是有效的吗？

注意：投掷对象或字符串或类似的东西对我来说似乎真的很糟糕，因为我们无法获取堆栈跟踪、验证实例等。

// This seems bad to me. Isn't it an anti-pattern?
throw {
   code: "",
   message: "",
   name: ""
}

Answer 1

Object.assign 方法不太健壮，更像是一种 hack，最好创建自定义错误类。 SO 上已经有一个in-depth discussion。

由于您想使用额外的字段，最多为内部错误引入 2-3 个自定义类，但即使这样也往往是矫枉过正：

• NetworkError 的一个，包含位置、路径和状态
• UiError 的一个带有组件和有问题的数据状态，可能还有 i18n 的消息代码
• 和一个通用的 RuntimeError 或类似的，用于未知情况

对于每个潜在的事件都有一个错误类是没有意义的。与 Java 不同，JavaScript 中没有检查异常，目标是有足够的数据来解决问题，而不会过度设计它。如果您可以有意义地捕获并在对话框中显示比 message 字符串所能容纳的更多的数据，那就去吧。

在设计自定义错误时，请从处理和显示此信息的位置和方式开始。然后看看你是否可以很容易地收集到你扔的这些数据。如果您没有全局错误对话框或集中错误报告，可能只使用默认错误就足够了，您可以将所有数据放入消息中。

有一种特殊情况，当您想使用错误作为控制逻辑的手段时。尽量避免它，JavaScript 非常灵活，不使用throw 作为让上层选择不同执行路径的方法。但是，它有时用于重试网络请求，然后它应该有足够的数据。

内置的Error对象已经有以下字段：

• 姓名
• 留言
• 堆栈

在每个错误中，stack 和 message 是有助于解决问题的两条关键信息。因此，重要的是，当你重新抛出它时，使用这样的东西（对于所有非 IE）：

catch (err) {
 throw new Error('New error message with added info', { cause: err });
}

最后，检查其他人在做什么会有所帮助：

• GraphQL 的GraphQLError
• VueJS 中的错误处理 hooks（没有自定义错误）

而且，JavaScript 不仅有Error，还有：

• 评估错误
• 范围错误
• 参考错误
• 语法错误
• 类型错误
• URI错误
• 聚合错误

你也可以在适当的时候扔掉它们。

请注意，大多数处理视图的 UI 框架没有自定义错误类，也不需要。