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. <jackalm...@gmail.com> wrote: > On Tue, Feb 28, 2017 at 10:12 AM, /#!/JoePea <j...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
