Managing Node.js Callback Hell with Promises, Generators and Other Approaches

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.

[ Parent | on HN ]

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

But at that point, you're not using promises anymore so all bets are off.

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.
  });

No problem bubbling that.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]