[moe]

becomes something like

You comfortably omitted the error handling (admittedly the original snippet didn't have that either).

However in production code it's not optional, and that's where node.js code tends to get really nasty.

[glenjamin]

On this point I don't disagree, for this case you'd expect the data access layer to deal with all the database errors and return something useful to the request layer:

    app.get('/price', function(req, res) {
      products.fetchOne(function(err, product) {
        if (err) {
          res.render('error', { error: err });
        } else {
          res.render('product', { product: product });
        }
      });
    });

[moe]

you'd expect the data access layer to deal with all the database errors and return something useful

There you nailed the problem. It's a constant headache, especially since library authors have different ideas about the format and semantics of "something useful".

Before you know it you have re-invented your own half-baked exception-framework, to normalize/wrap/re-throw those ErrBacks. And then a week later you notice that rollback/retry and event cascades need a whole new level of treatment.

There's a reason why mature event-frameworks such as Twisted have never quite taken over the mainstream. It's sad to see node burn all its powder on a niche programming-style that just doesn't fly for the majority of applications.