Error.isError S4

中文标题：Error.isError 提案

提案概览

提案速览

该提案引入静态方法 Error.isError，用于可靠地检测一个值是否为原生 Error 实例，解决了跨全局对象下 instanceof 不可靠以及通过 Symbol.toStringTag 伪造 Object#toString 的问题。

Note

以下 README 来自上游仓库，其中的阶段或状态标注可能滞后；当前信息以提案概览为准。

Error.isError

ECMAScript 提案、规范草案和参考实现，用于 Error.isError

规范由 @ljharb 起草。

该提案目前处于流程的第 4 阶段。

我向委员会提出了关于 Symbol.toStringTag 的担忧，以及之前可靠且不可伪造的 Object#toString 调用现在将不再可靠。委员会的一致意见是，只要所有内置对象都有原型方法，至少在没有内部槽时抛出错误，就足以作为可靠的品牌检测方法。

然而，Error 实例（及其子类）的内部槽仅在 Object#toString 本身中检查——在存在 Symbol.toStringTag 的世界中，没有留下任何可靠的检测方法。

当然，instanceof Error 是不可靠的，因为它会对跨全局对象（例如，来自 iframe 或 node 的 vm 模块）的 Error 实例产生假阴性。

此列表并非详尽无遗。

调试：对于人类（即使不总是对程序）来说，了解值的类型非常有帮助。因此，知道某物是否是“真正的”原生错误是有价值的信息，可以提供给错误报告库。
序列化：像 RunKit 这样的平台需要安全地序列化值，并在用户的浏览器中重构或描述它们。品牌检测对此至关重要。
structuredClone：这个 HTML 方法（在 node 中也有）会进行品牌检测，并且对原生 Error 有特殊行为。JS 程序需要一种方法来提前知道是否会应用这种行为。
集中式错误收集：从 iframe（同源）向顶层框架报告错误，在那里收集、评估所有错误，并报告给个性化服务器以供稍后调查。然而，throw 语句可以抛出任何类型数据未知的异常，并且需要验证要收集的数据。thrownData instanceof Error 不能满足 Error 的要求，因为被抛出的错误会继承另一个全局对象的 Error 实例，意味着 contentWindow.Error 是抽象类，需要 thrownData instanceof document.getElementsByTagName('iframe')[0].contentWindow.Error 才能满足验证。

您可以查看渲染为 HTML 的规范。