.error() catches all errors from external libs

[spion]

I mentioned this on IRC, but I'm also going to put it here, since I think its probably not possible to automatically deal with this one :(

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(); 
    }); 
}).error(function(e) { 
    console.log("This should not execute", e); 
});

This also occurs if I have a node module that depends on bluebird which I'm developing in parallel with the app that depends on it. For example, while developing anydb-sql and doxbee (which depends on anydb-sql), I can't use .error() in doxbee because that might also catch programmer errors within anydb-sql.

It gets slightly worse :( If I run npm dedupe (which is often done before browserifying or before pushing node_modules to production) the behavior of my program will change -- since now both modules will depend on the same instance of bluebird.

Anyway, in general, the assumption that an external promises-based module never has bugs is just too big -- too often this is not the case.

I realize that the situation with error types coming from most promise-based libraries is not so good, but I don't think automatic rejection marking is going to solve it -- so far it seems to be making some things worse :(

The easiest way out of this one is for promise users to settle on a flag, e.g. SomeError.prototype.isPromiseRejection = true, and for error() to all errors that have it. Then people can use create-error to make rejections

Automatic rejection marking should be possible, yes -- but opt-in, maybe via a method that converts the library in a similar manner that .promisify does that for callbacks.

What do you think?

[petkaantonov]

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

[Raynos]

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

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

[spion]

@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)

[Raynos]

@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 ?

[tgriesser]

@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?

[spion]

@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.

[petkaantonov]

@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.

[benjamingr]

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); 
});