3 ms·
becomes something like You comfortably omitted the error handling (admittedly the original snippet didn't have that either). However in production code it's n
by moe 15y ago
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.
- deleted 15y ago[deleted]
- glenjamin 15y agoOn 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 15y agoyou'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.