-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Possibly unhandled Error" when settling synchronously in .any #432
Comments
Well, you:
A var p1 = getApi1();
var p2 = getApi2();
any(p1, p2).then(function(){
// change state to indicate networking works since one resolved
// or perform reports otherwise
});
p1.then(p1DoneHandler); If p2 resolved but p1 did not you'd get a silent failure here. You can always attach an empty catch handler to a promise to indicate you are explicitly suppressing errors - I think the point in unhandled rejection tracking is to make unhandled errors opt-out and not opt-in in the special cases you don't want to see them. |
The problem is that the way bluebird handles rejections, differs depending on whether the settling is synchronous or asynchronous. If everything is settled asynchronously, no 'unhandled Error' stacktraces occur, and it is presumably ignoring them (as I would personally expect from If the intention is to treat unhandled errors as unhandled even when |
While writing a module for determining the length of a stream (this is sometimes determined synchronously and sometimes determined asynchronously, depending on the type of stream), I ran into some strange "Possibly unhandled Error" stacktraces being printed to my console.
I eventually managed to write a reproducible minimal testcase (it's CoffeeScript, apologies, but the process should be clear nevertheless). In the process of writing this testcase, I also found that that stacktrace differed considerably depending on the exact approach used, but I'm not sure whether this is relevant.
Version: 2.6.2, from npm
The summary of the issue is as follows: When any of the Promises in a
.any
call are settled synchronously (whether resolved or rejected), a "Possibly unhandled Error" will be printed to the console after the.any
aggregrate Promise has already resolved itself.Expected behaviour: The
Error
should be silently ignored, as the.any
Promise has already successfully resolved, and the use of.any
indicates that we don't care about the rejected Promises, as long as at least one has resolved.Output:
The text was updated successfully, but these errors were encountered: