Bluebird: Unhelpful error message "Error: [object Object]"

[mheitzibm]

I got an Error thrown from ensureErrorObject in util.js whose message is simply "Error: [object Object]". That doesn't tell me anything about my problem. Please do JSON.stringify instead.

[benjamingr]

Thanks for the feedback, care to add a reproducing PR?

[benjamingr]

Reproducing sample I mean, so we can make a PR

[mheitzibm]

Sure, I'll see what I can come up with.

[AndrewHuffman]

@benjamingr I don't have reproduction steps for you, but I believe the problematic code is here: https://github.com/petkaantonov/bluebird/blob/master/src/util.js#L236

Can we consider using util.inspect for this?

[AndrewHuffman]

Forgot about browsers. JSON.stringify with a replacer?

[benjamingr]

We support browsers that do not have JSON.parse :D

The issue here is objects with getters and/or proxies can cause side effects when iterated and that sounds like potentially really nasty bugs.

If the object has a constructor it'd print [object Type] which is better.

If you have a safe solution I'm game.

[AndrewHuffman]

The issue here is objects with getters and/or proxies can cause side effects when iterated and that sounds like potentially really nasty bugs.

Object.getOwnPropertyDescriptor may help with this.

[mheitzibm]

This shows the problem in Node.

var Promise = require('bluebird');

var def = Promise.defer();
setTimeout(function () {
    def.reject({death: true});
}, 
1000);
def.promise.then(function (val) {
    console.log(name + ': got result ' + val);
});

Here's the output

$ node app.js
Unhandled rejection Error: [object Object]
    at Object.ensureErrorObject (/home/mheitz/node_modules/bluebird/js/main/util.js:261:20)
    at Promise._rejectCallback (/home/mheitz/node_modules/bluebird/js/main/promise.js:469:22)
    at PromiseResolver.reject (/home/mheitz/node_modules/bluebird/js/main/promise_resolver.js:97:18)
    at null._onTimeout (/home/mheitz/repo/app.js:6:6)
    at Timer.listOnTimeout (timers.js:119:15)

[benjamingr]

@mhamann oh, this is going to be an extremely hard sell then, sorry.

The policy is that you should always reject with Error objects. If you reject with anything else, you don't get a stack trace and the name of the error is the least of your worries. We wrap with errors when promisifying libraries (promisifyAll and promisify).

I'm sorry, but I don't think Petka will be interested. He might reopen if he is.

[mheitzibm]

Maybe you could test for JSON.stringify since most browsers have it. Use it if it exists, otherwise fall back to what you do today.

[benjamingr]

But there are cases this won't work (with getters/proxies) and the use case is very rare anyway since you're not throwing an error. My recommendation is that you throw Errors.

If you feel strongly about this, you can of course add a custom unhandled rejection handler and deal with it yourself:

process.on("unhandledRejection", function(reason, promise) {
    console.log("Possibly Unhandled Rejection", JSON.stringify(reason)); 
});

This will cause your wanted behavior for all promises in your code.

[AndrewHuffman]

@benjamingr We already have that but bluebird wraps obj + "" version of the object: https://github.com/petkaantonov/bluebird/blob/master/src/util.js#L263. Why can't this just simply do new Error(obj) ?

Also, I'm not able to enumerate getters when I test using JSON.stringify. I'm going to play around with this some more but I'm not certain that's an issue. Circular references will need to be able handled, though (or cut at a depth of 1).

[benjamingr]

Why can't this just simply do new Error(obj) ?

Because rejecting with anything other than what was provided violates the specification and makes the library ES2015 promises and Promises/A+ incompatible, basically. Assuming I understood your suggestion.

[AndrewHuffman]

Gotcha.

@mheitzibm - We should look into monkey patching the reject to identify where these are coming from.

[puppeteer701]

I am getting the same error when using library with nodejs.

What is the solution here?

[stephenotalora]

@benjamingr why was this closed? This issue is still happening ....