Question

这是一个更普遍的问题，但我想其他人也遇到过这个问题 - 比如看看这个问题：Ember.js: how to analyze error in vendor.js

我正在研究一个更大的基于Ember的应用程序，如果发生错误，我有时会得到相当神秘的堆栈跟踪，类似于此示例：

TypeError: e.indexOf is not a function
at e.func (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:6039)
at e.get (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:11:29357)
at Object.o [as isPath] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:5640)
at Object.u [as set] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:10630)
at n.set (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:16:725)
at n.cancel (https://XXX/assets/YYY-707bc84342df7a5350ea91fcc2b9bf53.js:1:20788)
at o.join (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:7:6400)
at Function.u.join (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:12315)
at https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:9:30923
at Object.h [as flaggedInstrument] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:12:18911)

由于所有内容都引用了/assets/vendor-*.js文件，因此找出错误发生的确切位置非常费力。

目前，我尝试根据访问的端点和我对软件的了解来推断出错误的位置。但是，这是非常不可靠和非结构化的，因为考虑到我的代码库的大小，错误通常非常模糊。

例如，在这里，显然调用indexOf（）的对象（可能是数组）可能是未定义的或null，因此，调用indexOf（）就不起作用，因此错误。但是猜猜有多少数组在几百个大型源文件中使用indexOf（）; - ）

在这种情况下，我是否可以使用更好，更结构化的方法进行调试？

Answer 1

通过在Chrome调试器中将“暂停在异常上”并检查出现故障的库是什么，您可能可以查看所使用的库js文件。之后，您可以将ember-cli-build.js中的库引用从libraryx.js更改为libraryx.src.js或特定库的等效库。

ember.js：如何基于资产/供应商进行调试 - * .js

1 个答案: