[MatthewPhillips]

Is this really the most common style? It seems to me that this is more common:

  doAsyncCall(function onSuccess(result) {
    // do things
  }, function onError(err) {
    // No need to check, it's really an error.
  });

This is much cleaner and lets you reuse error handling functions.

[firefoxman1]

What a great pattern! I have to disagree though, (err, data) seems much more popular. Until now I'd never seen this (fantastic) style.

[snprbob86]

I don't think that this style is fantastic. This means that the pair of success/error callbacks is not reified, so there isn't a single object to pass around or manipulate. The result is that composition is harder. In order to create higher order asynchronous operations, like those in Async.js [1], you need to either pass two arguments or use an array or object to pair the error handlers together. This is particularly important if you want to return a pair of handlers from a function.

In the two-callback model, the most common way to reify the handler pair is with a {success:...,error:...} object. This is much better than function(x,y,z,success,error), but still has the problem that you now need to override two handlers if you want to wrap some completion logic, regardless of success/failure. For example, if you want to close a file handle, win or lose, you need to provide two new functions.

Composition greatly benefits from a singular object. The Node.js approach is the (err,data) callback. It's an extremely simple and successful approach. The other approach are promises/futures, which internally can be implemented with one or more callbacks, but provide a nice clean interface for composition. You could get that with success/error objects, but you're exposing the internals rather than an interface, like you should be doing. A good promise interface would let you choose an implementation without tying you to any particular callback model.

[1] https://github.com/caolan/async

[jahewson]

My experience of the f(onerror, onsuccess) pattern is that it does not scale well when multiple functions are nested, as the error-handling code gets pushed further and further down the page from the actual error site it handles.