Unintuitive error handling

[humanchimp]

Bluebird is a really nice project. I especially like the error handling semantics it adopts by default.

However, when using .nodeify I have encountered some troubling behavior. I brought this up yesterday on IRC, and @spion thought it could be a bug. So I am raising the issue here for further discussion

var log = console.log.bind(console)

function doStuff(callback) {
  return new Promise(function (resolve, reject) {
    reject(new Error("example error"));
  })
  .nodeify(callback);
}

function doStuff2(callback) {
  return doStuff(callback).finally(log);  // or ".then"
}

doStuff(log);

doStuff2(log);  // possibly unhandled exception

When I call doStuff(log), the log becomes my error handler, as it is passed into .nodeify. Bluebird considers this error to be handled in this case.

doStuff2(log) internally calls doStuff(log) and so I would expect that the error would be satisfied by the log callback, but upon attaching finally (or then) handlers, it seems to somehow revive the error from doStuff, and logs a "possibly unhandled exception" stack trace to the console.

I'm not sure if it's a bug, but I would like to understand why this occurs, if it is determined to be the expected behavior, so that I can avoid writing code that might cause this behavior.

[petkaantonov]

There is unfortunately a hidden assumption in .nodeify - that you won't use both the promise and callback interface at the same time. This could be more explicit by returning undefined when nodeify is used with a callback so that doStuff2 function simply wouldn't work at all.

At the time I didn't bother to make nodeify return undefined as I thought that nobody will try to use callback and promise at the same time as it simply doesn't make any sense.

[benjamingr]

+1 for returning undefined

[humanchimp]

OK, I agree that .nodeify should return undefined in the presence of a callback. Thanks for responding.