Closed mikecann closed 9 years ago
As far as I understood this topic, the promise can not know wehter it is at the end of the chain, because it only "knows" about itself.
From the perspective of the function that returns a Promise (like the one in #47), you can not call done
on the promise before returning, because you then you would not allow the calling code to attach errorhandlers to the chain.
When I was busy with a huge AS/Flex App that used Promises that we brought to iOS Platform using the AIR SDK, at some point we had strange behaviour we could not explain. One Idea was that all those anonymous functions that you (can) use a lot when using Promises and all those Promise references that are only tight to the scope of a function (e.g. Command.execute()
) are not referenced anymore and might get garbage collected.
We couldn't prove this, but we decided to have a static pool of promise references that was also responsible for getting rid of the references when they are done (chaining finally
) and to call done
on the promise.
So in short terms the message is: find a way either by code or by convention (which could be enforced by codeanalysis if you have a CI pipeline or a powerful IDE), to make it difficult to forget the call to done
.
All that said, I agree this is a major gotcha, but I think its a structural one, enforced by the concepts of the language.
@honzabrecka: nice link
Awesome thanks guys, really helpful info.
Hi again,
In the docs you mention one of the biggest pitfalls of promises is the error swallowing:
the solution is to use done():
as this is quite a major gotcha I dont suppose that there is a way for a promise to rethrow an error if it reaches the end of the chain and there is no handler?