Hacker News Reader

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.)

View on HN

Normal 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.

Correct 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.

Yup. 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.

Reply on news.ycombinator.com