3 ms·

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 preven

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.

londons_explore 4y ago
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.
- bluepnume 4y ago
  The alternative is just to leave the promise as rejected, and expect the developer to .catch when they're ready.
  - Aeolun 4y ago
    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.