This is more of a general question, but I imagine others have encountered this problem as well -- see for instance this SO question: Ember.js: how to analyze error in vendor.js
I am working on a larger Ember-based application, where, if errors occur, I sometimes get rather cryptic stack traces, similar to this sample:
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)
Since everything refers to /assets/vendor-*.js files, it is very laborious to find out exactly where the error has occurred.
At the moment, I try to deduce where the error has occurred based on the endpoint accessed and my knowledge of the software. However, this is highly unreliable and unstructured, since the errors are very often highly vague, given the size of my code base.
For instance here, it is obvious that an object on which indexOf() is called (presumably an array) is probably undefined or null and, as such, calling indexOf() on it doesn't work, hence the error. But guess how many arrays use indexOf() in a couple of hundred large-ish source files ;-)
Is there a better, more structured approach that I can use to debug in such situations?
Aucun commentaire:
Enregistrer un commentaire