How come resolving a settled Promise doesn't throw?
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
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
> > 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
> > 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss