How come resolving a settled Promise doesn't throw?

Isiah Meadows isiahmeadows at gmail.com
Tue Feb 28 20:58:38 UTC 2017


Also, making promise resolution idempotent makes dealing with things way
easier. Similarly, most deferred libraries ensure their resolution is
idempotent.

On Tue, Feb 28, 2017, 13:20 Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Tue, Feb 28, 2017 at 10:12 AM, /#!/JoePea <joe at trusktr.io> wrote:
> > f.e.
> >
> > ```js
> > let resolve
> > let p = new Promise(r => resolve = r)
> >
> > resolve(5) //  resolves the promise.
> > resolve(4) // noop (in Chrome), but why not throw an error?
> > ```
> >
> > I only tested in Chrome, and I'm assuming it follows spec, but I could be
> > wrong.
> >
> > I'm asking because it seems that throwing an error will prevent shots in
> the
> > foot, so that code doesn't assume that resolving on an already resolved
> > Promise worked, although it didn't. It seems like it can lead to
> unexpected
> > failures.
>
> That's correct behavior, yes.  In general, it's because the internal
> state of a promise is meant to be unobservable unless you're
> specifically listening to it.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170228/5906980b/attachment.html>


More information about the es-discuss mailing list