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

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