Q comes with optional support for “long stack traces,” wherein the stack
property of Error
rejection reasons is rewritten to be traced along asynchronous jumps instead of stopping at the most recent one. As an example:
function theDepthsOfMyProgram() {
Q.delay(100).done(function explode() {
throw new Error("boo!");
});
}
theDepthsOfMyProgram();
usually would give a rather unhelpful stack trace looking something like
Error: boo!
at explode (/path/to/test.js:3:11)
at _fulfilled (/path/to/test.js:q:54)
at resolvedValue.promiseDispatch.done (/path/to/q.js:823:30)
at makePromise.promise.promiseDispatch (/path/to/q.js:496:13)
at pending (/path/to/q.js:397:39)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
But, if you turn this feature on by setting
Q.longStackSupport = true;
then the above code gives a nice stack trace to the tune of
Error: boo!
at explode (/path/to/test.js:3:11)
From previous event:
at theDepthsOfMyProgram (/path/to/test.js:2:16)
at Object.<anonymous> (/path/to/test.js:7:1)
Note how you can see the function that triggered the async operation in the stack trace! This is very helpful for debugging, as otherwise you end up getting only the first line, plus a bunch of Q internals, with no sign of where the operation started.
This feature does come with somewhat-serious performance and memory overhead,however. If you're working with lots of promises, or trying to scale a server to many users, you should probably keep it off. But in development, go for it!