No stack trace provided if a rejected Promise's .done() method is called

[nomcopter]

When Promise.reject(new Error('error')) is ran, a Possibly unhandled Error... is thrown in the browser with a very useful stack trace.

However, when you .done() the promise, no useful stack trace is produced.

[benjamingr]

How is that stack trace useful in any way o_0?

[benjamingr]

How is that stack trace useful in any way o_0?

[nomcopter]

It's the stack trace of what is running in the console, it is much more useful when it is actually running in code instead :)

The Object.InjectedScript is part of Chrome's internal console code, the anonymous function is what I typed into the console.

[nomcopter]

It's the stack trace of what is running in the console, it is much more useful when it is actually running in code instead :)

The Object.InjectedScript is part of Chrome's internal console code, the anonymous function is what I typed into the console.

[benjamingr]

Yeah, I understand what stack trace I'm seeing, what I don't understand is why you find it useful in this case - now if you had Promise.longStackTraces() called first or had nested async calls I'd understand what you're asking for better.

[benjamingr]

Yeah, I understand what stack trace I'm seeing, what I don't understand is why you find it useful in this case - now if you had Promise.longStackTraces() called first or had nested async calls I'd understand what you're asking for better.

[nomcopter]

In the first case, it tells me the exact line that the rejected promise was produced. In the second case, all it gives me is the error message and a line number deep within bluebird. Here is an example of how the stack trace is useful:

In a large project, if things break and all I see is an error with a line deep in bluebird, I wouldn't know where to even start looking.

[nomcopter]

In the first case, it tells me the exact line that the rejected promise was produced. In the second case, all it gives me is the error message and a line number deep within bluebird. Here is an example of how the stack trace is useful:

In a large project, if things break and all I see is an error with a line deep in bluebird, I wouldn't know where to even start looking.

[petkaantonov]

Since the .done() error is just thrown in the process normally (throw e)it doesn't know how to format it, the possibly unhandled error formatting is actually very custom work and the red color is from using .console.error

[petkaantonov]

Since the .done() error is just thrown in the process normally (throw e)it doesn't know how to format it, the possibly unhandled error formatting is actually very custom work and the red color is from using .console.error

[nomcopter]

That custom work is very helpful and essential for debugging. Without it my workflow when this happens is:

1. Breakpoint on bluebird.js:174
2. Retrigger error
3. Check res.e.stack

Maybe add a configurable option (or default) to log the stack trace before it throws the error from a .done()ed promise?

[nomcopter]

That custom work is very helpful and essential for debugging. Without it my workflow when this happens is:

1. Breakpoint on bluebird.js:174
2. Retrigger error
3. Check res.e.stack

Maybe add a configurable option (or default) to log the stack trace before it throws the error from a .done()ed promise?

[petkaantonov]

I'd prefer just automatically doing it by default without even exposing configuration but I never personally use .done() so I am not sure if that's ok to .done() users

[petkaantonov]

I'd prefer just automatically doing it by default without even exposing configuration but I never personally use .done() so I am not sure if that's ok to .done() users

[nomcopter]

I agree that it should be automatic. It is important that it doesn't look like two errors were thrown though.

We use .done() in our project in to be explicit when we have finished working with a particular promise - especially because of coffeescript's implicit returns. It also matches the Promises/A+ spec a bit more since more other Promise libraries only actually throw errors on rejected Promises if .done() has been called.

[nomcopter]

I agree that it should be automatic. It is important that it doesn't look like two errors were thrown though.

We use .done() in our project in to be explicit when we have finished working with a particular promise - especially because of coffeescript's implicit returns. It also matches the Promises/A+ spec a bit more since more other Promise libraries only actually throw errors on rejected Promises if .done() has been called.

[petkaantonov]

Do you have any ideas how to make it obvious they are not two errors? Remember that the log cannot come after the error so we can't do e.g. Additional stack trace:

[petkaantonov]

Do you have any ideas how to make it obvious they are not two errors? Remember that the log cannot come after the error so we can't do e.g. Additional stack trace:

[nomcopter]

Ideas (best first):

1. Simply console.warn saying something like ".done() called on rejected promise, throwing to window" and the stacktrace before throwing it.
2. Append the additional stack trace to the actual error (res.e.message += trace), but people might be expecting any thrown errors' messages to remain intact.
3. Attach the stack trace to a global and console.warn its location before throwing the error. i.e. Promise.getStackTraceForError(errorId) or window.lastBluebirdStack

[nomcopter]

Ideas (best first):

1. Simply console.warn saying something like ".done() called on rejected promise, throwing to window" and the stacktrace before throwing it.
2. Append the additional stack trace to the actual error (res.e.message += trace), but people might be expecting any thrown errors' messages to remain intact.
3. Attach the stack trace to a global and console.warn its location before throwing the error. i.e. Promise.getStackTraceForError(errorId) or window.lastBluebirdStack

[petkaantonov]

Turns out I can log right away after the error is thrown, so it looks like this atm:

[petkaantonov]

Turns out I can log right away after the error is thrown, so it looks like this atm:

[petkaantonov]

Actually I will change it to console.warn, the expanding arrow button is confusing

[petkaantonov]

Actually I will change it to console.warn, the expanding arrow button is confusing

[nomcopter]

Awesome. Thanks a lot. Why did you opt to only output this if longStackTraces have been enabled?

[nomcopter]

Awesome. Thanks a lot. Why did you opt to only output this if longStackTraces have been enabled?

[petkaantonov]

Because without it there wouldn't be any additional stack trace

[petkaantonov]

Because without it there wouldn't be any additional stack trace

[nomcopter]

Huh, I get the same in Chrome regardless. Not sure why.

(I get the same output even if I call Promise.longStackTraces() before creating the first promise)

[nomcopter]

Huh, I get the same in Chrome regardless. Not sure why.

(I get the same output even if I call Promise.longStackTraces() before creating the first promise)

[petkaantonov]

I changed the condition to if ("stack" in e) {

[petkaantonov]

I changed the condition to if ("stack" in e) {

[nomcopter]

Perfect. Thank you so much for the quick fix as always! :)

[nomcopter]

Perfect. Thank you so much for the quick fix as always! :)