You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
vm: Error.prepareStackTrace behaves inconsistently across versions #21270
In Node 8.x (tested with 8.11.2), it will just output a normal stack, ignoring the prepareStackTrace defined in the context.
It seems that in Node 8, the prepareStackTrace from the currently running context (i.e. the one where .stack is called) is used, whereas in Node 6, the one where the Error was instantiated is used.
Note that this only happens when the Error is passed along, and not when it's a thrown exception. I suspect that's because when it's thrown, DecorateErrorStack is run, which gets the stack before it's passed to the main context:
@hashseed i think people would draw a line sort of like "myErrorInstance" => "myErrorInstance's Constructor" => "That constructor .prepareStackTrace", so using the origin context would make sense.
personally though, i would argue that prepareStackTrace should be deprecated and removed
I don't think removing prepareStackTrace at this point is a feasible option, even though it's not part of the standard. Same applies to Error.stack in the first place. There are some effort though to standardize it, and I'm hoping something similar to prepareStackTrace will be part of it too.
In the example above, the stack property is formatted lazily in the current realm. There, we load prepareStackTrace from the global error object (code).
I agree the old behavior makes more sense, especially since we currently use a different prepareStackTrace depending on when exactly stack is first accessed. Opened https://crbug.com/v8/7848.
Thoughts on closing this? I'm inclined to close this on the grounds that it's a V8 issue and a bug should be opened in the V8 issue tracker. This is an undocumented API as far as Node.js goes, and the "new" behavior here is now on all current release lines except Node.js 6.x which is going EOL in 6 months.
Activity
targos commentedon Jun 11, 2018
What about v10?
devsnek commentedon Jun 11, 2018
this feature isn't actually provided by node, it's a debug feature from v8. iirc it's still documented but we should probably remove that.
/cc @nodejs/v8
edit: we haven't even documented it.
bengl commentedon Jun 11, 2018
@targos Node 10 (tested with 10.4.0) produces the same result as Node 8.
hashseed commentedon Jun 12, 2018
@schuay fwiw I think the old behavior of using
prepareStackTracefrom the origin context makes more sense. Wdyt?devsnek commentedon Jun 12, 2018
@hashseed i think people would draw a line sort of like "myErrorInstance" => "myErrorInstance's Constructor" => "That constructor .prepareStackTrace", so using the origin context would make sense.
personally though, i would argue that prepareStackTrace should be deprecated and removed
jdalton commentedon Jun 12, 2018
I'm not a fan of removing useful APIs without alternatives.
devsnek commentedon Jun 12, 2018
@jdalton tc39/proposal-error-stacks#20 (comment)
the api might useful if it existed anywhere else besides v8 but it doesn't...
hashseed commentedon Jun 13, 2018
I don't think removing
prepareStackTraceat this point is a feasible option, even though it's not part of the standard. Same applies toError.stackin the first place. There are some effort though to standardize it, and I'm hoping something similar toprepareStackTracewill be part of it too.schuay commentedon Jun 13, 2018
A d8 repro:
In the example above, the stack property is formatted lazily in the current realm. There, we load
prepareStackTracefrom the global error object (code).I agree the old behavior makes more sense, especially since we currently use a different
prepareStackTracedepending on when exactlystackis first accessed. Opened https://crbug.com/v8/7848.Trott commentedon Oct 26, 2018
Thoughts on closing this? I'm inclined to close this on the grounds that it's a V8 issue and a bug should be opened in the V8 issue tracker. This is an undocumented API as far as Node.js goes, and the "new" behavior here is now on all current release lines except Node.js 6.x which is going EOL in 6 months.
devsnek commentedon Oct 26, 2018
its already got a bug and fix in v8. it's just waiting on my rewrite of stack decoration (i'm about 50% done). i think this is safe to close.
Trott commentedon Oct 26, 2018
If it's awaiting some code change in Node.js, then I think we can leave it open. I thought it was entirely in V8-land.
Trott commentedon Oct 3, 2019
Hello! Just doing the one-year-later check! Is there anything that can or should be done with this issue?
BridgeAR commentedon Jan 4, 2020
This prints 'hello' in Node.js v12.x and above, so it seems like it works as expected.