改进了错误日志中的 JSL 堆栈跟踪当前缺少错误时显示的 JSL 日志。当前，它显示以下内容：
- 抛出了什么类型的错误
- 哪一行引发了错误（但不是该行位于哪个文件中）
- 运行的 JSL 文件的主体（整个主体，即使它非常长）
- 有时，运行的 JSL 文件主体会突出显示引发错误的行。但这并不总是有效。
获取以下调试信息将会更有参考价值：
- 抛出了什么类型的错误
- 调用函数的堆栈跟踪，其中包含有关每个调用函数中哪一行引发错误的详细信息。
当您可以自己阅读文件并查找出错行时，打印带有高亮显示的 JSL 文件其实没什么用。它占用了日志中的空间，让我不得不滚动过去才能看到实际抛出的错误。
自动化和脚本关于：登录错误中改进的JSL堆栈跟踪即使它没有嵌套在内置函数中，也可以将它用于具有1层内置函数的用户定义函数。
回复：改进错误日志中的 JSL 堆栈跟踪
@DavidLeber写道：
嗯，不总是正确的选择！
我记得有些情况下，错误指向定义变量的那一行代码。
但错误是由完全不同的一行代码引起的。
所以，这种追踪逻辑似乎有其道理：“变量是在哪里赋值的，这一定是错误的根源。” 但这种逻辑很容易误导人……
错误跟踪：JMP 尝试执行“帮助”操作
回复：改进错误日志中的 JSL 堆栈跟踪嗯，并非总是如此……
很多情况下，JMP 不会报告代码行号： 错误信息 - 是哪一行？
当用户编写代码时，这种程度的信息就已经是个问题了，但现在人工智能编写代码，这个问题就更大了。
还有更多错误。
这些错误可能非常出乎意料。
由于目前错误报告机制的局限性：
当你不知道在哪里找的时候，它们就很难找到。
回复：改进错误日志中的 JSL 堆栈跟踪相关需求： 错误类型
回复：改进错误日志中的 JSL 堆栈跟踪-
