-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
return/throw #3
Comments
I suppose it would be possible to support that in most cases. If the function throws then pass the error to the final callback, if it returns something other than undefined / null, then execute the next function and pass in that value. The problem is that it then no-longer behaves in a way you'd just expect. Most node.js functions that accept a callback don't care what you return, and I don't want to stray too far from the normal node.js style. Also, what if you wanted to pass undefined as an argument to the next function? I think trying to add this would complicate things, even though I understand why you might want it supported. For now, I would recommend just wrapping your sync function with one that accepts a callback... if you find you're doing that a lot I could create a shorthand for it, something like async.wrap(fn) |
I see. Of course I didn't mean to force the changes, just maybe a special I might be wrong or miss something, but how to reliably instruct --Vladimir |
How about checking a function property? Something like |
Actually, you can easily implement it by yourself, like async.toAsync = function (syncFunction) {
return function() {
var callback = pop(arguments);
try {
callback(false, syncFunction.apply(null, arguments));
} catch(err) {
callback(err);
}
}
} and then use it like this: async.waterfall([
async.toAsync(function() { return 2; }),
async.toAsync(function(x) { return 1/x; }),
], callback); |
I think this should be closed. |
Hi!
Is it possible to teach
.waterfall()
take functions which simply return the result on success (instead ofcb(null, result)
) and throw an error (instead ofcb(err)
) on error condition? That way could be possible to extract the logic of actions to vanilla functions which could be both sync/async, thus making.waterfall()
neutral to asynchronity. Also that could simplify exception handling, since either programmatic throw or real exception would be equivalent.What do you think?
TIA,
--Vladimir
The text was updated successfully, but these errors were encountered: