Hacker News Reader

One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method.

I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code that you can instantly recognize as missing if someone forgets to check for err in the callback.

If you can stick with the style, it's fairly difficult to write code that doesn't deal with errors gracefully.

I agree. One of the advantages of the (err, result) style is that it puts error handling directly in your face. The `result typeof Error` style does not.

In any case all I care about is that we choose one, and (err, result) is gaining traction, which is fine. While many are excited about domains, I am not. From my perspective, in practice, it will just add another incompatible style onto the pile.

Yeah, domains seem like a desperate solution. Will be interesting to see what eventually becomes the standard.

How do you deal with code where the author forgot to handle all of the failure cases and invoke the callback?

To be honest... since you can't try/catch, you can't do much.

You can catch the exception with something like this:

  process.on('uncaughtException', function (err) {
    console.err("Uncaught exception: " + err);
    console.err("Uncaught exception stack: " + err.stack);
  });

I use the built-in clustering module (implementation is very simple) so a simple worker crash will result in the error being logged & the worker being restarted.

That's about the best you can do, unfortunately. You could always monkey patch the lib if you can figure out where it's crashing.

I recommend Longjohn(https://github.com/mattinsler/longjohn) for these sorts of situations; the extra stack trace lines become invaluable.

Fix the code.

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.

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

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

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.

with (er, result) -> you may find yourself polling both er and result.status

in practice I find I this means relatively ugly or unhelpful error messages through the first parameter are successively refined by conditionally setting helpful status and message attributes on the second

this style is kinda consistent with ajax calls on the client that may either fail, or return data containing an error.

That way is longer without reason, you must first define in the function scope both variables error and result; the latter only receives assignation when no error has been generated.

    function doAsyncCall(callback){
        var error, result;
        // .. do some async stuff
        // assign error if there was one or result when everything went fine
        if( !error ){ result = data; }
        callback(error, result);
    }