-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
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.