Ember debugging, unhelpful errors, can ES6 source maps help?

Hi,

This is like my fourth time in 4 years of me trying to get into Ember.js. It’s going alright this time around, much has improved.

However, one thing I just cannot get over are the error messages. Maybe it’s been solved and I’ve just misconfigured source mapping in Chrome, but I still get error msgs like these:

I often kinda know where to look because I reload after every small change. But after a big refactor for instance you can get so damn lost in these errors. What’s up with all this ember.debug.js, why can’t I just see where my code went “boom”, proper file and linenr and all?

2 Likes

I don’t know about your source maps.

But what’s not usefull about that error? You are trying to render into an outlet which doesnt exist.

You’re right this error msg is fine. I guess it’s the stack trace I’m missing. where did my error occur?

That IS the stacktrace. Having the handlebars lib thrown an exception the error will obviously come from within the ember.* file.

If your error is located in, say, a controller or a route your stack trace will end at whichever method had the faulty code in it (as stack traces tend to do :stuck_out_tongue:).

For an example. Look at my current error below. The first image is the stack trace, and the new is after I click the place in the stack trace where the exception was thrown:

Thanks for your reply Jakob.

I know what stacktraces are, and I do see errors like the ones you posted. Those are easy to locate and trace right back to code I wrote. But what about the error in my screenshot? Let me put it this way:

If you cloned my repo, booted ember, visited the homepage and saw the error i placed in my first screenshot, would you know to what file and line you would go to fix it? I don’t.

Sorry. I know you know about stack traces, didn’t mean to sound like you didn’t. :slight_smile:

I know it’s a bit messy but the error messages have come a long way and yes, most of the time I would know exactly what to do. Using the Ember-cli does provide you with a lot of debugging info that is presented a bit nicer, so if you’re able to use it please do. For stuff like what you posted a screenshot of, yes I would instantly know what to do.

The thing that’s a bit wierd about your screenshot is that the stack property, actually tells you about an error in /assts/vendor.js on line 30286 at character 21. If it’s a fairly plain Ember setup then that does sound like it’s your code being referenced. But why it’s not in the list, I don’t know.

If not… Then no, I would have to do a search throughout the project. That would suck.

Btw… crazy about your nickname.

The thing that’s a bit wierd about your screenshot is that the stack property, actually tells you about an error in /assts/vendor.js on line 30286 at character 21. If it’s a fairly plain Ember setupt then that does sound like it’s your code being referenced. But why it’s not in the list, I don’t know.

Maybe because I was using Emblem templates?

hahah, Thank You! I’m quite pleased with it myself :slight_smile:

Yes, I reckon that might be the case then.

I got really excited before when I realized blackboxing is a thing in chrome devtools:

But then to get this to help filter out irrelevant files, we have to be in a debugger. I always have to put a debugger somewhere in the console.logged stack, but that’s an additional step.

I wonder if there’s some way these two views of stack traces could work together?

What you’re dealing with is what is known as the Ember run loop. It’s what makes Ember updates to your templates efficient but is also a nuisance when tracking down bugs :wink:

if you add the line mentioned here:

to your app/app.js file, it should help you track things down …

2 Likes

I concur, the stack traces definitely shouldn’t show vendor.js line 23492 or app.js line 12312, and should show where the error really came from. Anyone know if there are plans from the team to improve on this?