Re:Managing Node.js Callback Hell with Promises, Generators ...
by gfxmonk on Tuesday February 04, 2014 @04:51PM
(#7180493)
It's not just a best practice - exceptions raised from async code callback simply do not work right (they'll never make it back to the caller). In practice an exception raised from a callback will take a very short trip the wrong way through the stack (whatever happened to invoke your callback is _not_ the original caller, otherwise you wouldn't need callbacks), and end up as a toplevel uncaught exception, killing your entire process in nodejs.
Re:Managing Node.js Callback Hell with Promises, Generators ...
by jarrett on Tuesday February 04, 2014 @05:09PM
(#7180593)
Good point. I had previously thought the callback in some way "remembered" who called it, and could bubble an exception back up to the caller's try/catch block. But you've set me straight. Further proving the point that you can't just throw exceptions whenever you want.
Re:Managing Node.js Callback Hell with Promises, Generators ...
by spion on Wednesday February 05, 2014 @07:45AM
(#7183383)
Actually, you can throw exceptions from within .then just fine and they will be always bubbled. You just cant go
function g() {
return somePromise.then(function() {
setTimeout(function() {
throw new Error();
}, 500);
});
}
g(); // crash
However if you use a promise-based timeout too:
function f() {
return somePromise.then(function() {
return Q.delay(1000).then(function() {
throw new Error("Oops");
});
});
}
f().catch(function(e) {
console.log(e.message); // logs Ooops.
});
Re:Managing Node.js Callback Hell with Promises, Generators ...
by cpeterso on Tuesday February 04, 2014 @10:44PM
(#7181753)
Don't promises address this exception problem because the top level code is calling the then () function, which can then throw an exception to the appropriate caller?
Re:Managing Node.js Callback Hell with Promises, Generators ...
by jarrett on Wednesday February 05, 2014 @11:00AM
(#7184461)
Yes, I believe so. I was just addressing a the original suggestion, which was to avoid using promises and use vanilla callbacks instead. In that architecture, exceptions don't seem to be workable.
Re:Managing Node.js Callback Hell with Promises, Generators ...
by spion on Wednesday February 05, 2014 @06:37AM
(#7183166)
Promises normalize all exceptions in promise code to bubble up the chain - as such, they do make it back to the caller.
(However, they do leave async exceptions from callbacks alone - only domains can handle those)
For better or worse, Node's best practice seems to be to propagate errors via the err parameter in each callback. E.g. `function myCallback(err, data)` where data represents the result of a successful computation.
One could reasonably debate whether this was the best possible design. Some people like exceptions, for one thing. For another, JS's dynamic typing, combined with multiple layers of error propagation, could lead to mishandling of the errors--you expect your callback to be passed error A, but it actually gets error B from elsewhere in the callback chain.
But this pattern is ingrained by now. If people started deviating from the pattern and using exceptions, you'd end up with an even worse monstrosity. Every bit of calling code would have to handle both styles of errors.