Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

when.any behavior with empty array #330

Closed
benjamingr opened this issue Jun 16, 2014 · 3 comments
Closed

when.any behavior with empty array #330

benjamingr opened this issue Jun 16, 2014 · 3 comments
Assignees
Milestone

Comments

@benjamingr
Copy link
Contributor

Currently, with the following code both when.any([]) and when.any([resolvesToUndefinedFirst,...]) behave exactly the same way.

I'm wondering why that is and what the rationale about it is. At first glance it seems to me that when.any([]) (and similarly when.some) should throw a range error.

(Similarly, when calling when.any without an array argument).

Thanks!

Related: petkaantonov/bluebird#233

when.any([]).then(function(val){
    document.body.innerHTML = JSON.stringify(val); 
});

var p = when.resolve(undefined);
when.any([p]).then(function(val){
    document.body.innerHTML += " "+ JSON.stringify(val); 
});
// ends up with body being `undefined undefined`

Online example: http://jsfiddle.net/3RAk8/

@briancavalier
Copy link
Member

@benjamingr Yeah, it seems pretty reasonable to reject for any kind of N-winner race where it's known up front that there simply aren't enough inputs to ever fulfill it. That jives with the notion that at the point where it's known that the race can't be fulfilled, it rejects. I think we considered doing that for 3.0, but it fell off the radar.

Using a RangeError as suggested in petkaantonov/bluebird#233 seems pretty reasonable--better than returning never() like race() has to do :(

@unscriptable and @scothis, this would be a breaking change for 3.x, but honestly, I think I'd rather just call it a bug and fix it in 3.3 than wait for 4.0 (when.some is already deprecated anyway). Any thoughts or objections?

@unscriptable
Copy link
Member

I know we'll likely break a few users' code, but this does feel like a bug.

👍

@briancavalier
Copy link
Member

Fixed by #332. Thanks again @benjamingr!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants