Allow every and filter callbacks to receive errors as first argument

[bwindels]

The fact that the callbacks for the every and filter functions don't accept an error object can be restrictive in some situations. For example when you do I/O operations in the iterator, you might want to differentiate between an I/O error and a result that got filtered in the final callback. Right now the API does not allow you to differentiate between the two cases.

I understand that these functions were designed this way because of certain nodejs API (path.exists), but maybe we could have alternative versions of these functions (everyWithError, filterWithError) or have smart behavior that can handle both cases. The latter solution would consider the first argument of the callback to be an error only if two arguments were passed. That error would be passed to the final callback as the first argument as well, as happens with the other functions.

I might try to write a patch for the last solution sometime soon.

[LabiKyo]

+1, I need that too

[caolan]

I agree this would be nice to add but it is backwards incompatible, the hard part is managing the release not writing the code, and I keep putting it off ;)

[gyllstromk]

I have a code proposal for this here: PopCometLabs@2aa2f82

It uses a new function name to avoid backward compatibility collisions.

I'll submit a PR if this works for you.

[aearly]

This issue got closed in a bulk update.

I agree that it is odd that an async function would return a boolean as the first argument. The only core API method that does this is fs.exists, and it is becoming deprecated.

We should change this when we are doing a breaking release to expect an function (err, bool) {} callback, and maybe provide a wrapper for backwards compatibility.

[kobezzza]

+1

[LinusU]

Could this be added to the 2.0 milestone? Would love to see this resolved 👍