Promise rejections don't resolve the argument

# raul mihaila (10 years ago)

Can somebody please provide a rationale for why promise reject functions don't resolve the argument, if the argument is a promise, before they pass it to the handlers, like promise resolve functions do?

Promise.resolve(Promise.reject(3)).catch(console.log.bind(console)) // logs 3 Promise.reject(Promise.resolve(2)).catch(console.log.bind(console)) // logs a promise

# Fabrício Matté (10 years ago)

Promise.resolve and the Promise executor function's resolve argument lets you "delegate" the fulfillment of the given promise to another promise object. That is essential for composability.

In the other hand, Promise.reject and the Promise executor function's reject argument are to be called at the point when the given operation fails and you already have enough info to reject it with a reason (that is, reject is similar to a throw when compared to non-async code). In this context, it wouldn't make much sense to delegate the failing of a promise, since reject is always called when you're 100% positive that the operation has already failed. Just like throw, you can pass any object as the reason argument to reject(), but good practices tell you to only pass error objects.

# Fabrício Matté (10 years ago)

*By "any object" I mean "any value". Anyway, it would be interesting to see a real use case for passing a promise as reject reason.

# Axel Rauschmayer (10 years ago)

Regular behavior is (you reject with a

Promise.resolve(3).then(console.log.bind(console)) // logs 3
Promise.reject(3).catch(console.log.bind(console)) // logs 3

Promise.resolve() only unwraps promises passed to it, because that is needed for chaining:

asyncFunc1()
.then(result1 => asyncFunc2()) // (A)
.then(result2 => console.log(result2));

then in line (A) returns a promise that is resolved with what its callback returns. Because resolving unwraps, asyncFunc2 can return a promise and result2 will contain the result of resolving it (which is what you want for chaining).

# raul mihaila (10 years ago)

Maybe it would make sense only when you know that the operation fails but you don't know the whole exact reason. Like if (something went weird but not sure what) throw getSomeSpecificErrorFromSomewhere(). But indeed it seems improbable that you will ever need that, and it still could be written using a derived promise that throws. Thank you!

# Fabrício Matté (10 years ago)

Yes, delegating to another promise which then rejects should cover that use case. =]