1

So far in programming (Swift for iOS) for async functions i've been using two callbacks to handle the completion of the async function. One is executed if the function completes without error ("success") and the other if the function errors ("failed").

I've noticed that node.js uses error first callbacks where the first parameter of the callback is an error which is null if no error occurs. It then comes down to the user to check if the error is null and handle the situation appropriately based on the result of this check.

My question is; is there any reason, in the realms of optimisation or best practices in programming, to use either of these methods over the other, or does it come down to personal preference and consistency?

Personally I can't see how it would matter that much either way but my concern is I may have missed something.

Joe Blakes
  • 103
  • 7
  • 2
    node.js has one of each. The typical async callback in node.js is how you describe, but then the promise system which is now standard in ES6 has a separate callback for success and failure. It really is a matter of design preference. There are situations where one is more convenient than the other and situations where the other is more convenient. Either one can always be turned into the other with a few lines of code, so there's nothing one can do that the other can't. – jfriend00 Dec 05 '15 at 17:59
  • @jfriend00 Okay thank you for the response – Joe Blakes Dec 05 '15 at 19:02
  • Possible duplicate of [Why does node prefer error-first callback?](http://stackoverflow.com/questions/40511513/why-does-node-prefer-error-first-callback) – Alexander O'Mara Nov 27 '16 at 07:31

0 Answers0