"Just My Code" for stack traces?

[benjamingr]

Throwing a raw idea out there:

I just saw this question where a user was confused about a stack trace they got when using puppeteer:

Unhandled Rejection at: Promise Promise {
  <rejected> Error: Navigation Timeout Exceeded: 30000ms exceeded
    at Promise.then (C:\...\pupet test\node_modules\pupp
eteer\lib\NavigatorWatcher.js:71:21)
    at <anonymous> } reason: Error: Navigation Timeout Exceeded: 30000ms exceede
d
    at Promise.then (C:\...\pupet test\node_modules\pupp
eteer\lib\NavigatorWatcher.js:71:21)
    at <anonymous>

The point is, the first few stack frames are irrelevant to the user. If the first stack frame showed the part in their code that caused the error it would have been a lot more useful.

I'm wondering if we can improve the debugging experience of users by giving them "Just My Code"

Just My Code

Node could expose a "Just My Code" exception mode similar to the way stacks work in the Chrome devtools. Running Node with the flag would hide any frames from node_modules folder.

Thoughts?

[apapirovski]

Seems pretty well suited to the user-land, no? Just use a custom Error.prepareStackTrace that filters out Node.js core modules & node_modules code. There are some edge cases but I don't think that's a good reason to make it be a part of the core.

(Can also do all kinds of other neat things with the API https://github.com/v8/v8/wiki/Stack-Trace-API)

[bnoordhuis]

One argument in favor is that only core can disambiguate stack frames with 100% certainty.

vm.runInThisContext('throw new TypeError()', {filename:'vm.js'}) throws an exception that looks like it comes from the vm module, but doesn't, and there's really no way for a user land hook to tell.

That said, I don't necessarily think hiding stack frames is a good idea. I can quickly see that turning into a bigger hindrance than a help, with people filing bug reports with unhelpful stack traces. Getting a good bug report is already more the exception than the norm, in this day and age.

[techsin]

maybe a plugin that make colors of files in node_modules gray and less contrast so you can see what file are yours

[jasnell]

If it can be done reasonably well I think this would be excellent to have but I definitely share @bnoordhuis' concern around it. It wouldn't hurt to have some non-committal experimentation around it.

[techsin]

so what im saying wont hide it, but only visually color it differently in terminal.

[techsin]

i created a simple script that accomplishes what i was thinking....
I simply put it in main app.js file

const colors = require('colors');
Error.prepareStackTrace = (err, arr) => {
   let lines = err.stack.split('\n');
   lines = lines.map(x => x.includes('node_modules') ? colors.grey(x) : x);
   lines = lines.join('\n');
   err.stack = lines;
};

then in one of my routes of app

throw new Error('test');

result ....

https://github.com/v8/v8/wiki/Stack-Trace-API

[AyushG3112]

Problem with just different Coloring is when you use SDKs which transfer the flow of control a lot.

I use the aws-sdk a lot and the stack traces there are not useful because it is filled with the stack of the internal function calls, hiding frames from node_modules option will help a lot in this case.

[techsin]

didn't explain how coloring won't help sdk traces which live in node_modules...

[joyeecheung]

Just realize that we have a default Error.stackTraceLimit = 10, so unless users set this to a higher value, many of our internal stack frames are probably not going to be visible to them anyway if their code throws in a sufficiently deep call stack.

Another idea would be to exclude all the stack frames up to the first frame of user code (on master it's usually Module._compile and 8 frames below)

[BridgeAR]

This is partially fixed since a while. Using console.log or util.inspect on errors marks Node.js stack frames grey and adds an underscore to node_modules names. We could go ahead and add a color to node_modules frames but not everyone wanted that. Should this stay open or shall we consider it as solved?

[jasnell]

I'd say let's consider it solved. If someone wishes to make further enhancements, a PR with a concrete proposal would be ideal. Closing