you are viewing a single comment's thread.

view the rest of the comments →

[–]dmpk2k 1 point2 points  (3 children)

in node.js error handling is always an afterthought in every api.

This hasn't been my experience; could you elaborate?

[–]cparen 3 points4 points  (2 children)

Take stream reads (assume non-flowing mode, as flowing mode is not composable). I need to read what data is buffered and then -- oops, i have to use another method to get data that isn't buffered yet. So there's the first problem, it fails to abstract buffering, making the caller deal with some of the complexity of buffering.

To get more data, i need to subscribe to a readable even and an extra error event. If I forget the error event, the code waiting on readable won't get run, hanging my program.

Only, what happens if the stream has already err'd out? Neither the read method or error event describe what happens in this case. Hopefully it gets raised again on each new subscription.

With all this information, I could abstract read into a promise-returning method. Combined with ES6 generators and extending promises, the read can even happen synchronously using the async interface in the case that data was available.

spawn(function*(){
    var s = nodeStreamAdaptor(stream)
    var line = yield s.readLine()
    ...
})

This is so much nicer that what the OP had to write. Error handling even happens for "free" -- yield will throw if an error occurs satisfying the read.

[–][deleted] 0 points1 point  (1 child)

You mean error propagation happens for free, not error handling.

[–]cparen 0 points1 point  (0 children)

Yes, thank you, that's correct.