How come resolving a settled Promise doesn't throw?

Isiah Meadows isiahmeadows at gmail.com
Wed Mar 1 05:45:24 UTC 2017


BTW, there's still usefulness of making resolution/rejection idempotent and
never throwing. IMHO, I'd just like to see this die.

-----

Isiah Meadows
me at isiahmeadows.com

On Tue, Feb 28, 2017 at 4:36 PM, Jordan Harband <ljharb at gmail.com> wrote:

> Although now that I think about it, it wouldn't have to care about the
> promise state, `resolve` and `reject` could just throw if they're invoked
> more than once.
>
> On Tue, Feb 28, 2017 at 1:35 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
>> 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/20170301/a30c747f/attachment-0001.html>


More information about the es-discuss mailing list