.error() catches all errors from external libs about bluebird HOT 8 CLOSED

Yes .error() is now broken because of course the external promise libraries are always going to call the reject callback explicitly.

from bluebird.

Why does this fail? BB2.then shouldn't call reject.

Is it because BB.then calls reject if a rejected promise is returned ?

from bluebird.

@Raynos yeah I think the thing is that when assimilating an untrusted thenable, its impossible to differentiate between thrown errors (possibly even bugs) and rejections from BB.

What could be useful? To agree on a flag/convention that errors which have the flag isPromiseRejection = true will be catched by .error() and then tgriesser's create-error can be used to easily make and throw such errors. (or simply Bluebird.RejectionError)

Basically it comes down to this -- if library authors of libraries based on promises don't make a distinction, the distinction cannot be made. I think the best you can do in that case is to filter-out TypeError, ReferenceError, RangeError as programmer errors and attach .isPromiseRejection = true to every other kind of error (this would likely be better if opt-in and... I guess it could be done with functions like rejectify/rejectifyAll over misbehaving promise-based libs -- or is that a horrible name? :D)

from bluebird.

@spion I don't understand how it's impossible. You mean a rejected thenable is impossible to differentiate from being rejected by reject(err) or throw err ?

from bluebird.

@petkaantonov is it necessary that the same Error objects be used (with the global freeze) on all copies of the lib rather than providing them per-instance?

from bluebird.

@Raynos yes, and is also impossible to differentiate either from typo errors :|

And as we discussed it wouldn't matter even if reject(err) were easy to differentiate from throw, as most authors utilizing promises would simply throw their errors.

from bluebird.

@Raynos When assimilating thenable it will always call the reject callback, it will never throw, otherwise it wouldn't be a promise library. The reference error was already caught and turned into rejection in the other library long before even calling .cast.

from bluebird.

For the record I'd just like to add that the behavior @spion describes is exactly what I expect when assimilating thenables from other libraries - and is in my opinion the expected behavior.

That said, I understand why it's not desirable and agree that it should be fixed.

What about giving all assimilated rejections a base type of AssimilatedRejectionError and being able to catch that explicitly? That seems to both address the issue and not change current behavior.

var BB = require('bluebird');
var BB2 = require('bluebird/js/main/promise')(); 
BB.cast(1).then(function() { 
    return BB2.cast(1).then(function() { 
        return makes.reference.errors(); 
    }); 
}).catch(BB.AssimilatedRejectionError,function(e){
     // handle whatever
}).error(function(e) { 
    console.log("This should not execute", e); 
});

We can also introduce a helper for this:

var BB = require('bluebird');
var BB2 = require('bluebird/js/main/promise')(); 
BB.cast(1).assimilateAsThrow().then(function() { 
    return BB2.cast(1).then(function() { 
        return makes.reference.errors(); 
    }); 
}).error(function(e) { 
    console.log("This should not execute", e); 
});

from bluebird.