Handled rejected promises are claimed as unhandled in some cases

[scf2k]

Handled rejected promises are claimed as unhandled in some cases. Can be reproduced with example like this:

var QFS = require('q-io/fs');

QFS.lastModified('/nonexistent')
.fail(function(err) {
    console.log('error caught!');
});

This code will generate a warning on application exist. Seems to be related directly to Q, not Q-IO.

[arikon]

@domenic Have a look at this, please. It blocks us from moving to q 0.9.x.

[domenic]

Is this Node 0.10-only?

I don't have much time this week, but maybe next...

[scf2k]

@domenic no, it's not node dependant.

[domenic]

This seems to be q-io related, since the following does not cause the problem:

var Q = require('q');

Q.reject("boo!")
.fail(function(err) {
    console.log('error caught!');
});

investigating...

[domenic]

Nope, it's Q's problem. This triggers it:

var Q = require("q");

Q.reject("foo").get("bar").fail(function (err) {
    console.log("error caught!", err);
});

[domenic]

@kriskowal, I'm at my wits end on how to fix this one. I added a failing test in a branch, as above, but am not sure how to approach it myself.

[mikerobe]

This also causes spurious unhandled rejects:

q = require 'q'
defer = q.defer()
promise = defer.promise
promise.fail (err) ->
  console.log err

# removing this fin makes it work properly
promise.fin ->
  console.log 'fin'
defer.reject(new Error())

It may be a good idea to roll back the feature on the main releases until it's been thought out a little better (to avoid wrong and confusing errors)

[domenic]

@mikerobe, just as a point of etiquette, it is very rude to post bug reports in CoffeeScript to a JavaScript repo.

[mikerobe]

@domenic :) that's a good one

[tsgautier]

This is easily reproducible:

put this in a file called test.js:

var q = require('q');

var deferred = q.defer();
deferred.promise.then(function(e) { console.log("then", e); });
deferred.promise.fail(function(e) { console.log(e); });
deferred.reject('rejected');

run it:

$ node test

rejected
Unhandled rejected promise (no stack): rejected

[debug-ito]

This issue seems reproducible in Web browsers since the test at
https://rawgithub.com/kriskowal/q/master/spec/q-spec.html
emits the following error message to the console.

[Q] Unhandled rejection reasons (should be empty): []

I tried Firefox 20.0 and Chromium 25.0.1364.160 (both on Ubuntu 12.04), and both of them emit the message.

[satazor]

I've also encountered this bug, but it doesn't happen every time when running the same code multiple times.
Is there any way to disable this feature? I would prefer to disable it until this bug got fixed.

[Myztiq]

It would be nice to be able to disable this tracking via a configuration, or set a max size/count for the array to prevent memory being consumed on a production machine. Especially if that production machine does not "crash" or get restarted on a regular basis.

[domenic]

An API for disabling this is planned; see #265.

[Myztiq]

Thanks @domenic, I missed that issue.

[arikon]

@domenic @kriskowal Any progress on fixing this issue? It still blocks us from migration to q 0.9.x.

[kriskowal]

We might have to amputate.

[TrevorBurnham]

I'm wondering why this was closed... surely it's a bug that attaching additional success handlers to a promise causes additional entries to be added to unhandledReasons/unhandledExceptions? Here's a test case:

deferred = Q.defer();
deferred.reject(new Error('foo'));
deferred.promise.fail(function() {
  console.log(Q.getUnhandledReasons().length);  // 0
});
deferred.promise.then(function() {  /* ... */ });
deferred.promise.fail(function() {
  console.log(Q.getUnhandledReasons().length);  // 1
});

It's perfectly valid to attach success handlers to a promise separately from failure handlers, and should not complicate debugging. N'est pas?

[domenic]

Remember that .then and .fail create new promises, which are unhandled if the original one is unhandled.

On May 30, 2014, at 17:45, "Trevor Burnham" <notifications@github.commailto:notifications@github.com> wrote:

I'm wondering why this was closed... surely it's a bug that attaching additional success handlers to a promise causes additional entries to be added to unhandledReasons/unhandledExceptions? Here's a test case:

deferred = Q.defer();
deferred.reject(new Error('foo'));
deferred.promise.fail(function() {
console.log(Q.getUnhandledReasons().length); // 0
});
deferred.promise.then(function() { /* ... */ });
deferred.promise.fail(function() {
console.log(Q.getUnhandledReasons().length); // 1
});

It's perfectly valid to attach more success handlers than failure handlers to a promise, and should not complicate debugging. N'est pas?

Reply to this email directly or view it on GitHubhttps://github.com//issues/238#issuecomment-44703133.

[TrevorBurnham]

Yes, I was just realizing that. Not a bug, but a conceptual choice. Thanks for taking the time to clarify.