ember.js: debugging run loop stacktraces is not dev friendly, is it possible to add function arguments?

Hello,

Debugging in Ember is very cumbersome due to the run loop.

We have the stack trace but it is not always useful to understand from which part of the application code the exceptions come from - we have the line number but not the data used.

For example, for this regular exception:

  Error: Assertion Failed: calling set on destroyed object
    at new Error (native)
    at Error.EmberError (http://localhost:3000/assets/frontend/vendor.js:22060:21)
    at Object.Ember.default.assert (http://localhost:3000/assets/frontend/vendor.js:15395:13)
    at Object.set (http://localhost:3000/assets/frontend/vendor.js:25870:24)
    at exports.default.mixin.Mixin.create.set (http://localhost:3000/assets/frontend/vendor.js:39863:20)
    at Ember.Object.extend.flushCanonical (http://localhost:3000/assets/frontend/vendor.js:86749:14)
    at ember$data$lib$system$relationships$state$has$many$$ManyRelationship.flushCanonical (http://localhost:3000/assets/frontend/vendor.js:87069:22)
    at Queue.invoke (http://localhost:3000/assets/frontend/vendor.js:11433:18)
    at Object.Queue.flush (http://localhost:3000/assets/frontend/vendor.js:11498:13)
    at Object.DeferredActionQueues.flush (http://localhost:3000/assets/frontend/vendor.js:11303:19)"

For every new release of Ember, I overwrite ember-debug with the following lines:

  function set(obj, keyName, value, tolerant) {
    (...)
    if (obj.isDestroyed) {
      log("LV ember set "+keyName+" on destroyed object, returning false:","red");
      log(obj);
      return false;
      //Ember['default'].assert("calling set on destroyed object", !obj.isDestroyed);
    }

which tells me which object created the exception and the property who is getting set.

Is it naive to ask if such objects could be added in the EmberError stacks, if this is possible technically (not sure in javascript strict mode) with a routine which would systematically add the arguments of the function being called and the context - this would cover most of the cases. If not, maybe try to add more information on the most frequent errors in the run loop?

Thanks.

https://github.com/emberjs/ember.js/issues/2817