-
Notifications
You must be signed in to change notification settings - Fork 94
Closed
Labels
Milestone
Description
I am not sure why this wasn't in the original DOM spec, nor in @erights's concurrency strawman, but it's damn useful and not trivial to implement yourself.
Promise.prototype.finally = function (callback) {
return this.then(
value => this.constructor.resolve(callback()).then(() => value),
reason => this.constructor.resolve(callback()).then(() => { throw reason; })
);
};
Notably, like JS finally
clause:
- no value or reason is passed in to the finally code (i.e. to
callback
). - Does not affect the result, i.e. the resulting promise is still fulfilled with
value
or rejected withreason
, just like the original one, unless... - If the finally code blows up (i.e. if
callback
throws, or returns a rejected promise), it propagates that failure onward, instead of the original success or failure.
Use cases collected so far:
Metadata
Metadata
Assignees
Labels
Projects
Milestone
Relationships
Development
Select code repository
Activity
erights commentedon Sep 3, 2013
Absent from concurrency strawman, due only to oversight. I don't have experience with it. Sounds plausible. Can you point at some examples that illustrate well how it is useful?
domenic commentedon Sep 3, 2013
Here is one quick example, where we use it to clean up event listeners: https://gist.github.com/domenic/6419679
erights commentedon Sep 3, 2013
Nice.
On Sep 3, 2013 5:33 AM, "Domenic Denicola" notifications@github.com wrote:
annevk commentedon Sep 3, 2013
If we think we can get consensus on this, seems fine, otherwise, please lets not add new features that will delay the whole thing longer.
domenic commentedon Sep 3, 2013
Thanks for reining us in, @annevk :). My new position then is to default to not speccing it unless there's a sudden upswell of support due to your email this morning. We can always make it a high-priority addition later.
I'll close this in a day or so if said upswell does not appear.
mhofman commentedon Sep 3, 2013
I'd like to voice support for finally. I've had to implement it myself with the current version of DOM Promises and having it built-in would allow us to remove that piece of code which is basically there to restore a functionality that exists in synchronous operations.
domenic commentedon Sep 4, 2013
Closing for now. I would like this a lot but getting something done is more important.
jakearchibald commentedon Nov 4, 2013
Another use-case for this is hiding a spinner after a network request succeeds or fails https://gist.github.com/jakearchibald/785f79b0dea5bfe0c448
kriskowal commentedon Nov 4, 2013
@jakearchibald Thanks. I often use
finally
for test teardown…rauschma commentedon Oct 3, 2014
Minor correction:
Promise.prototype.finally
itself can’t be an arrow function – you are usingthis
inside it.stefanpenner commentedon Oct 3, 2014
@rauschma no it is correct, as it retains the this from the containing closure.
stefanpenner commentedon Oct 3, 2014
oops i misread @rauschma you are correct!
domenic commentedon Oct 3, 2014
Fixed the OP
21 remaining items