Promise finally

Ben Newman benjamin at cs.stanford.edu
Fri Feb 23 15:08:13 UTC 2018


This ordering of `console.log` calls seems to happen because
`Promise.prototype.finally` is specified in terms of
`Promise.prototype.then`, and is required to call `.then` twice.

Note the `Invoke(promise, "then", « thenFinally, catchFinally »)` here
<https://tc39.github.io/ecma262/#sec-promise.prototype.finally>, followed
by `Invoke(promise, "then", « ... »)` here
<https://tc39.github.io/ecma262/#sec-thenfinallyfunctions> (and here
<https://tc39.github.io/ecma262/#sec-catchfinallyfunctions>).

Any way you cut it, this adds an extra asynchronous
tick/step/hop/skip/jump, compared to merely calling
`Promise.prototype.then`.

Implementing `Promise` extensions in terms of `Promise.prototype.then` is a
good idea, because it means we don't have to add new fundamental operations
to the core `Promise` implementation. However, the translation from
`.finally` to `.then` comes at a cost. Once you understand that tradeoff,
hopefully this behavior seems more reasonable.

Ben

His errors are volitional and are the portals of discovery.
-- James Joyce

On Fri, Feb 23, 2018 at 9:32 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 2/23/18 9:30 AM, Michael Luder-Rosefield wrote:
>
>> Whenever you chain a promise with a then/finally, you're basically
>> letting the runtime look at the callbacks at some arbitrary point in the
>> future, no?
>>
>
> Not if the promise is already known to be resolved.  In that case, the
> exact behavior of the runtime is very clearly specified.
>
> -Boris
>
> _______________________________________________
> 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/20180223/22ef0023/attachment.html>


More information about the es-discuss mailing list