What does it mean to "not get a callback at all" in Node.js error handling in TJ's farewell post?
javascript, node.js
Solution
It means the error is lost in limbo since the operating function did not "get a callback", viz., the error is "swallowed", since there is no callback to handle it.
var foo = function(onSuccess, onFailure) {
// ...
// uh-oh, I failed
if(onFailure) {
onFailure(err);
}
else {
// well, that probably wasn't too important anyway...
}
}
foo(function() { console.log("success!"); } /* no second argument... */);
Note in synchronous coding (say, most Java) it's much harder for this to happen. Catch blocks are much better enforced and if an exception escapes anyway, it goes to the uncaught exception handler which by default crashes the system. It's like this in node too, except in the above paradigm where an exception isn't thrown it's likely swallowed.
Strong community convention could solve it in my trivial example above, but convention can not completely solve this in general. See e.g. the Q promise library which supports a `done` method.
Q.fcall(promisedStep1)
.then(promisedStep2)
.then(promisedStep3)
.then(promisedStep4)
.then(function (value4) {
// Do something with value4
})
.catch(function (error) {
// Handle any error from all above steps
})
.done();
The `done` call there instructs the promise chain to throw any unhandled exceptions (if the catch block were missing, or the catch block itself throws). But it is fully the responsibility of the programmer to call `done`, as it must be, since only the programmer knows when the chain is complete. If a programmer forgets to call `done` the error will sit dangling in the promise chain. I have had real production bugs caused by this; I agree, it's a serious problem.
I'll be honest that a lot of that block in the post doesn't make much sense to me. But I'm an experienced Node.js programmer and this is the only thing I can think that could mean.
Problem
Recently, I've been read the TJ's blog article: "Farewell Node.js". I'm not quite understand about the Node fails part. Here it is: Error-handling in Go is superior in my opinion. Node is great in the sense that you have to think about every error, and decide what to do. Node fails however because: - you may get duplicate callbacks - you may not get a callback at all (lost in limbo) - you may get out-of-band errors - emitters may get multiple “error” events - missing “error” events sends everything to hell - often unsure what requires “error” handlers - “error” handlers are very verbose - callbacks suck What specific problem is being referred to when the author writes "you may not get a callback at all (lost in limbo)"?