[Q] Unhandled rejection reasons (should be empty): ["(no stack) [object Object]"]

[alphanull]

This is the message I get in my console. On Chrome it reads a bit different:

[Q] Unhandled rejection reasons (should be empty): ["(no stack) undefined"]

This type of code seems to trigger the error:

Q.reject({ status: 404 });

Am I doing something wrong, might this be a bug in Q or is this something I can ignore?

[Nathan Stott]

You will get a better error message if you return an instance of `Error`.

Q.reject(new Error('status 404'))

--
You received this message because you are subscribed to the Google Groups "Q Continuum (JavaScript)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to q-continuum...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Kris Kowal]

That’s odd. I would expect, looking at the code, for that to show:

[Q] Unhandled rejection reasons (should be empty): ["(no stack) [object Object]"]

Yet still, I could probably help folks along a bit if it were:

[Q] Unhandled rejection reasons (should be empty): ["(reason not an Error) [object Object]"]

Thanks for pointing this out.

Kris

[alphanull]

Thanks for the tip! But now, I get:

[Q] Unhandled rejection reasons (should be empty): []

instead. Would that be the  result to expect?

And, do I only need to do this with rejections? What about:

Q.resolve({ status: 200, rawData : data });

[Kris Kowal]

Bitte sehen Sie https://github.com/kriskowal/q/issues/387

[alphanull]

Thanks for posting this to github! So this is _not_ me doing something wrong with Q, and I can sort of ignore this message for now, correct?

Am Mittwoch, 11. September 2013 18:17:46 UTC+2 schrieb Kris Kowal:

Bitte sehen Sie https://github.com/kriskowal/q/issues/387

[Domenic Denicola]

In general, you should think of rejection reasons like exceptions in synchronous functions, and fulfillment values as return values. Thus, just like synchronous exceptions, asynchronous reasons should always be Error instances (even though this is not enforced). But values can be anything.

[Kris Kowal]

As Domenic points out, the reason should be an Error object, though we do not enforce this. You will find that Error objects are much more useful in helping you debug. It’s great to annotate Error objects, though, particularly as in this case, you would add a "status" attribute that would be helpful for control flow downstream.

Kris

[alphanull]

Thanks for clarification!