Unhandled rejection when calling .return() with a rejected promise from another promise constructor

[overlookmotel]

1. What version of bluebird is the issue happening on?

v3.4.1

2. What platform and version? (For example Node.js 0.12 or Google Chrome 32)

Node v6.3.0, OS X 10.9.5

3. Did this issue happen with earlier version of bluebird?

Issue not present on bluebird v2.10.2.

---

When calling .return() with a value which is a rejected promise created from a different promise constructor, an unhandled rejection occurs.

var OtherPromise = Promise.getNewLibraryCopy();

var p = OtherPromise.reject( new Error('foo') );
Promise.resolve()
    .return( p )
    .catch( function() {} );

There's no unhandled rejection where p is an instance of Promise rather than OtherPromise.

Where OtherPromise == global.Promise (i.e. native JS promise), an unhandled rejection also occurs.

I'm actually not sure if calling .return() with a promise is meant to be supported anyway (it's not stated so in the docs) but it seems to work fine apart from this odd edge case.

As with issue #1158, I'm it's more that this is an inconsistent behavior rather than a terrible bug. And this issue is more for reference than an urgent call for it to be fixed!

[overlookmotel]

Also same issue with .catchReturn()

[overlookmotel]

I'm still seeing this issue in v3.4.5.

The following example results in an unhandled rejection:

var OtherPromise = Promise.getNewLibraryCopy();

var p = OtherPromise.reject( new Error('foo') );

Promise.resolve()
    .return( p )
    .catch( function() {} );

[petkaantonov]

It was reverted

[petkaantonov]

Doesn't this cause the warning too?

var p = OtherPromise.reject( new Error('foo') );

Promise.resolve()
    .then(function() {
        return p;
    })
    .catch( function() {} );

[overlookmotel]

Yes, you're right. But by that logic, shouldn't the following also create an unhandled rejection?

var p = Promise.reject( new Error('foo') );

Promise.resolve()
    .return( p )
    .catch( function() {} );

(it doesn't)

The point I was trying to make is that there's an inconsistency between what happens when p is an instance of Promise and when it's a promise from another constructor (either another bluebird constructor, or a native JS Promise).

My guess was that suppressing the error in all cases is the desired behavior since .return() is called sync.

[overlookmotel]

Or, I suppose you could argue that the error should never be suppressed, as then an error can get swallowed in:

function MyError(message) {
    Error.call(this, message);
}
require('util').inherits(MyError, Error);

var p = Promise.reject( new Error('foo') );

Promise.resolve()
    .then( function() {
        throw new MyError();
    })
    .return( p )
    .catch( MyError, function() {} );

[petkaantonov]

It's prohibitively expensive to go around reflecting whether the promise is some copy of bluebird, the check for if the promise is of the same library copy is very cheap so I didn't see downside in implementing it

[overlookmotel]

Ah I see. That makes sense. But what do you think of my example above where an error gets silently swallowed? (the 'foo' error gets ignored)

[petkaantonov]

yep in that case the error would be swallowed but doesn't seem like a big deal