Hacker News Reader

I was strongly against JS engines treating unhandled rejections as errors because a rejected promise is only ever not handled yet. Basically, in order to prevent blow-ups from unhandled rejections, you have to synchronously decide how to handle rejections. I feel like this goes against the asynchronous nature of promises.

View on HN

What would the alternative be? Handle them when the last reference to the promise disappears?

Seems that could hide more bugs when someone keeps a reference to a big set of promises for some other reason - keeping a reference to something shouldn't change that things behaviour.

The alternative is just to leave the promise as rejected, and expect the developer to .catch when they're ready.

That means you can have tons of promises that get silently rejected (and never handled).

I can see the appeal, but I can also see why they didn’t go that way.

Reply on news.ycombinator.com