3 ms·
How can the runtime conclude that the rejection is unhandled when there are outstanding references to the Promise? In other words, as long as the promise might
by deschutes 5y ago
How can the runtime conclude that the rejection is unhandled when there are outstanding references to the Promise?
In other words, as long as the promise might later be awaited or otherwise handled I don't see why the runtime should care. (That's the mental model I carry from other languages.)
- Footkerchief 5y agoNormal memory references aren't enough to prove that the promise's rejection is handled. It needs a reference in the form of one or more registered handlers -- which can be achieved by registering them immediately via the Promise.all in the above example.
- slaymaker1907 5y agoCorrect me if I'm wrong, but I think you can avoid this by doing: thingToUseLater.catch(() => {}) And just ignoring the result of .catch(). Promises are reusable so thingToUseLater can be waited on later when you want to block for it. Thanks for thoughts on this. I use promises a lot but this is an edge case I hadn't thought about. They are really pretty handy for build scripts since they make your dependencies explicit.
- beardedetim 5y agoYup. If you call catch, you've handled the promise. You would need to throw from within the callback in order for the promise itself to reject after that.