How come resolving a settled Promise doesn't throw?

[Jordan Harband]

That seems like it would allow synchronous observation of Promise state -
consider:

```js

function isResolved(promise) {
  try {
    new Promise((resolve) => {
      resolve(promise);
      resolve();
    });
  } catch (e) {
    return true;
  }
  return false;
}

```

On Tue, Feb 28, 2017 at 12:58 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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
>>
>
> _______________________________________________
> 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/93bb2c59/attachment-0001.html>