JS `Error Stacks` (提案)：标准化错误堆栈信息获取

好的，各位观众老爷们，今天咱们聊聊JS错误堆栈的标准化，这玩意儿就像是程序界的“犯罪现场”，出问题了，得靠它来找线索破案。但是，现在的“犯罪现场”参差不齐，有的清晰明了，有的模糊不清，严重影响了咱们“破案”的效率。所以，JS Error Stacks标准化提案就是为了解决这个问题，让咱们的“犯罪现场”更加统一、规范，方便我们快速定位bug。

第一部分：什么是JS Error Stacks？（别告诉我你不知道！）

简单来说，Error Stacks就是错误发生时，函数调用的顺序记录。想象一下，你调用了一个函数A，A又调用了函数B，B又调用了函数C，结果C里面报错了。Error Stacks会告诉你，这个错误是从C开始，经过B、A，最终到达了你的入口点。

Error Stacks的信息通常包括：

函数名 (Function Name): 哪个函数出了问题。
文件名 (File Name): 哪个文件里的函数出了问题。
行号 (Line Number): 哪一行代码出了问题。
列号 (Column Number): (可选) 哪一列代码出了问题。

有了这些信息，咱们就能迅速找到问题代码的位置，避免大海捞针。

第二部分：现状分析：Error Stacks的混乱世界

虽然Error Stacks看起来很简单，但现实情况却是各种浏览器、各种JS引擎的实现方式都不一样，导致Error Stacks的格式五花八门，简直就是一场“堆栈方言”大赏。

举个例子，同样一段代码，在不同的浏览器中产生的Error Stack可能长这样：

浏览器	Error Stack 格式
Chrome	`Error: Something went wrongn at foo (file:///path/to/your/file.js:2:5)n at bar (file:///path/to/your/file.js:5:5)n at baz (file:///path/to/your/file.js:8:5)n at <anonymous>:1:1`
Firefox	`foo@file:///path/to/your/file.js:2:5nbar@file:///path/to/your/file.js:5:5nbaz@file:///path/to/your/file.js:8:5n@file:///path/to/your/file.js:1:1`
Safari	`foo@file:///path/to/your/file.js:2:6nbar@file:///path/to/your/file.js:5:6nbaz@file:///path/to/your/file.js:8:6nglobal code@file:///path/to/your/file.js:1:1`
Edge (旧版)	`Error: Something went wrongn at foo (file:///path/to/your/file.js:2:5)n at bar (file:///path/to/your/file.js:5:5)n at baz (file:///path/to/your/file.js:8:5)n at Anonymous function (eval code:1:1)`

可以看到，每个浏览器的格式都不一样，函数名、文件名、行号、列号的提取方式也不同。这给Error Tracking工具（比如Sentry、Bugsnag等）带来了很大的麻烦，需要针对不同的浏览器编写不同的解析器，维护成本非常高。

第三部分：标准化提案：统一Error Stacks的格式

为了解决这个问题，TC39（负责ECMAScript标准化的委员会）提出了Error Stacks标准化提案，旨在统一Error Stacks的格式，让Error Tracking工具能够更加方便地解析Error Stacks，提高bug定位的效率。

标准化的目标是：

统一格式： 定义一个统一的Error Stack格式，所有浏览器都遵循这个格式。
可编程访问： 提供一个API，让开发者能够以编程的方式访问Error Stack的信息，而不是只能通过字符串解析。
Source Map支持： 更好地支持Source Map，方便调试压缩后的代码。

第四部分：标准化的具体内容（代码说话！）

标准化的Error Stack格式大致如下：

at FunctionName (FileName:LineNumber:ColumnNumber)
at FunctionName (FileName:LineNumber:ColumnNumber)
...

例如：

at foo (file:///path/to/your/file.js:2:5)
at bar (file:///path/to/your/file.js:5:5)
at baz (file:///path/to/your/file.js:8:5)
at <anonymous> (file:///path/to/your/file.js:1:1)

标准化提案还引入了一个新的API：Error.prototype.stackFrames。这个API返回一个数组，每个元素都是一个StackFrame对象，包含了Error Stack的详细信息。

try {
  throw new Error("Something went wrong!");
} catch (error) {
  if (error.stackFrames) {
    error.stackFrames.forEach(frame => {
      console.log("Function Name:", frame.functionName);
      console.log("File Name:", frame.fileName);
      console.log("Line Number:", frame.lineNumber);
      console.log("Column Number:", frame.columnNumber);
    });
  } else {
    console.log("Error Stack is not standardized.");
    console.log(error.stack); // Fallback to the old stack string
  }
}

每个StackFrame对象包含以下属性：

属性名	类型	描述
`functionName`	string	函数名，如果未知则为 `null`。
`fileName`	string	文件名，如果未知则为 `null`。
`lineNumber`	number	行号，如果未知则为 `null`。
`columnNumber`	number	列号，如果未知则为 `null`。
`isEval`	boolean	是否是 `eval` 代码。
`isConstructor`	boolean	是否是构造函数。
`isAsync`	boolean	是否是异步函数。
`isNative`	boolean	是否是原生函数。
`source`	string	(可选) 原始的堆栈帧字符串，用于兼容旧的解析器。
`getThis()`	function	(可选) 获取 `this` 的值，可能需要权限。
`getArgs()`	function	(可选) 获取函数的参数，可能需要权限。

第五部分：兼容性处理：新老交替的艺术

虽然标准化提案很好，但浏览器厂商需要时间来实现，而且现有的代码库可能已经依赖于旧的Error Stack格式。因此，我们需要考虑兼容性问题。

以下是一些兼容性处理的建议：

特性检测： 在使用Error.prototype.stackFrames之前，先检测浏览器是否支持该特性。

if (Error.prototype.stackFrames) {
  // 使用新的API
} else {
  // 使用旧的Error Stack字符串解析
}

Polyfill： 如果浏览器不支持Error.prototype.stackFrames，可以尝试使用polyfill来模拟该API。当然，polyfill的实现比较复杂，需要解析旧的Error Stack字符串，并将其转换为StackFrame对象。
Error Tracking工具的适配： Error Tracking工具需要同时支持新的Error.prototype.stackFrames API和旧的Error Stack字符串解析。当浏览器支持新的API时，优先使用新的API，否则使用旧的解析器。

第六部分：Source Map的支持：让压缩代码无所遁形

Source Map是一种将压缩后的代码映射回原始代码的技术。有了Source Map，我们就可以在调试压缩后的代码时，看到原始代码，方便定位问题。

标准化提案对Source Map的支持主要体现在以下几个方面：

fileName属性： StackFrame对象的fileName属性应该指向原始代码的文件名，而不是压缩后的代码的文件名。
lineNumber和columnNumber属性： StackFrame对象的lineNumber和columnNumber属性应该指向原始代码的行号和列号，而不是压缩后的代码的行号和列号。
Error Tracking工具的集成： Error Tracking工具应该能够自动加载Source Map，并将Error Stack中的文件名、行号、列号映射回原始代码。

第七部分：实际应用：Error Tracking工具的福音

Error Stacks标准化提案对Error Tracking工具来说，简直就是福音。有了统一的Error Stack格式和可编程访问的API，Error Tracking工具可以更加方便地解析Error Stack，提高bug定位的效率。

以下是一些Error Tracking工具可以利用标准化提案做的事情：

简化解析器： 只需要编写一个解析器，就可以支持所有遵循标准的浏览器。
提高解析效率： 可以直接访问StackFrame对象，而不需要进行字符串解析。
更准确的错误报告： 可以获取更准确的文件名、行号、列号，方便定位问题。
更好的Source Map支持： 可以自动加载Source Map，并将Error Stack中的文件名、行号、列号映射回原始代码。

第八部分：未来展望：Error Stacks的更多可能性

Error Stacks标准化提案只是一个开始，未来Error Stacks还有更多的可能性。

以下是一些未来的展望：

更详细的错误信息： Error Stack可以包含更多的错误信息，比如错误类型、错误消息、错误发生时的变量值等。
更好的性能分析： Error Stack可以用于性能分析，比如统计函数的调用次数、执行时间等。
更智能的调试工具： 调试工具可以利用Error Stack的信息，自动定位问题代码，提供更智能的调试功能。

第九部分：总结：标准化，为了更好的明天

总而言之，JS Error Stacks标准化提案是一个非常有意义的提案，它可以统一Error Stacks的格式，提高bug定位的效率，方便Error Tracking工具的开发，为JS开发者带来更好的开发体验。虽然标准化之路还很长，但我们相信，在TC39和各大浏览器厂商的共同努力下，Error Stacks的标准化一定会成为现实。

最后，希望各位观众老爷们能够支持Error Stacks标准化提案，让我们的JS世界更加美好！谢谢大家！

发表回复 取消回复

发表回复取消回复