W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [Futures] Possible to multiply-resolve a resolver in weird ways

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 06 Jun 2013 11:25:33 +1000
Message-ID: <51AFE50D.2040608@westnet.com.au>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Boris Zbarsky <bzbarsky@mit.edu>, DOM mailing list <www-dom@w3.org>
On 6/06/13 4:08 AM, Anne van Kesteren wrote:
> On Fri, May 31, 2013 at 5:46 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> In the resolver's resolve algorithm, the first step is to check the
>> "resolved flag" and bail out if set.  However the algorithm does not always
>> set this flag.  Is that purposeful?
>> Even if I posit that it is, this leads to a slightly weird situation. Say I
>> call resolve() with an object whose "then" getter accepts or rejects the
>> resolver.  Then we'll end up calling the then method and passing in our new
>> callbacks, even though the resolver is already resolved.
>> Should the resolved flag be rechecked after the [[Get]], perhaps?
> I now made the resolved flag checks on the public methods. The
> internal ones no longer have the check so API authors just have to be
> careful to avoid race conditions or use their own flag to prevent that
> from happening. This also required added a check in the Promise
> constructor.
> (I also implemented the renaming from Future to Promise per TC39
> discussion and removed the done() method.

Without .done(), what is the recommended way of ensuring unhandled 
errors get to window.onerror?

     .catch( function( err ) { setTimeout( function( err ) { throw err; 
} ); } );
Received on Thursday, 6 June 2013 01:26:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC