Open alebianco opened 9 years ago
checking p3.isRejected() and p3.isResolved() they both return true
That's a good illustration of the resolve behavior... Everything is deferred, and errors have priority. However, you can recover from errors and everything gets back on track. However, isResolved should be false in your example. Let me check into that.
so you say that a promise can error and be rejected after being resolved? it's hard to recover when both methods are invoked in an unspecified order (change the order of the resolve and throwError of d3 and the console output will be inverted)
i would expect that, when after p3 resolves there's an error, the promise group should fail as a whole. what feels wrong is that it resolves and also fails when all promises are completed ... maybe i'm completely wrong, i should go read a book about promises :confounded:
I added in deferred.throwError as a universal way of tripping error logic for asyncs like promise and streams. It's pretty low level. I don't understand how/why you are handling a promise twice (by rejecting and resolving it, presumably in two different locations). But, I agree I'll probably need to handle this case.
That was a minimal scenario to demonstrate the behaviour, this gist is closer to my current situation https://gist.github.com/alebianco/15a52b27460369e75115#file-main-hx-L45 i didn't expect that error to be caught by the previous promise error handler
I call that a quantum promise...
Consider this scenario:
it would trace:
since the promise resolves before throwing an error, i would expect it to only call the "then" method. Or if it errors first, only call the catchError method.
I guess my assumption could be wrong and this be the intended behaviour but it feels wrong ...