Promise.prototype.finally(developers.google.com)
developers.google.com
Promise.prototype.finally
https://developers.google.com/web/updates/2017/10/promise-finally
63 comments
> In either case we need to call hideLoadingSpinner(). Until now, we had no choice but to duplicate this call in both the then() and the catch() block.
I always chain a `then` after `catch` in these situations.
I always chain a `then` after `catch` in these situations.
fetch(...)
.then( response => data.response = response )
.catch( error => data.error = error )
.then( () => closeThatLoader() )Another upside of the proposal is that if you need to reuse the fetch promise somewhere else it will retain the reject status if the promise fails. The proposal is more akin to:
fetch(...)
.then(response => {
closeThatLoader();
return success(response);
})
.catch(error => {
closeThatLoader();
throw error;
});Am I the only one that really dislikes the "catch" behavior?
The fact that catching a promise marks it as resolved and triggers subsequent "then"s rather than "catch"s. It means that every callback needs to be aware of every other callback and their own place in the order, so that only the last catch statement doesn't rethrow the exception.
Something like $.Deferred() allows you to set 10 "fail" callbacks independently, which helps a lot when the original promise is generated by a deeply nested method and different stages of the chain add their own handling.
The fact that catching a promise marks it as resolved and triggers subsequent "then"s rather than "catch"s. It means that every callback needs to be aware of every other callback and their own place in the order, so that only the last catch statement doesn't rethrow the exception.
Something like $.Deferred() allows you to set 10 "fail" callbacks independently, which helps a lot when the original promise is generated by a deeply nested method and different stages of the chain add their own handling.
The catch behavior mirrors try {} catch {} blocks. If you don't need a catch, don't catch, and let it bubble up. Try to keep the things you catch to a bare minimum. The rethrow decision is largely the same for Promises as try {} catch {} blocks, too.
(It's more apparent too in the async/await space where catch is even literally try {} catch {}.)
(It's more apparent too in the async/await space where catch is even literally try {} catch {}.)
Thanks for the reply. I guess my contention as someone just starting to use vanilla promises is that it feels like try/catch isn't the appropriate metaphor to use here.
In my specific case I'm passing a lot of promises to user-made scripts. then/catch seems to make things more brittle. As I said though, I'm new to them.
In my specific case I'm passing a lot of promises to user-made scripts. then/catch seems to make things more brittle. As I said though, I'm new to them.
That's totally fair. There are learning curves involved and sometimes tradeoffs aren't entirely obvious why they were made.
If you get a chance, particularly play with async/await code somewhere. There's a lot of misconception that async/await replaces Promises or is very different from Promises, but the reality is much closer that Promises were a necessary building block for async/await, and some of the trade-offs in Promise design are there to support async/await, based on work that had already been done in other languages.
Maybe if you try to write some of your work as async/await it might give you insights into your architecture and how to make it feel less brittle.
If you get a chance, particularly play with async/await code somewhere. There's a lot of misconception that async/await replaces Promises or is very different from Promises, but the reality is much closer that Promises were a necessary building block for async/await, and some of the trade-offs in Promise design are there to support async/await, based on work that had already been done in other languages.
Maybe if you try to write some of your work as async/await it might give you insights into your architecture and how to make it feel less brittle.
That is assuming that you chain promises like
a
.then(b).catch(bhandle)
.then(c).catch(chandle)
a
.then(aout => b(aout).catch(bhandle))
.then(bout => c(bout).catch(chandle))
You may want to do something _and then_ throw the error, to let it reach the caller. In your example it would mean to run "closeThatLoader" and later throw the error. It's really cumbersome without `finally`
That’s not equivalent though — in the article’s example, imagine `element` is `undefined`, for example. `then()` wouldn’t be called in that case.
Yes, trying to understand what the point of .finally is when a subsequent .then after .catch seems to achieve the same thing. What am I missing?
A final .catch().then() swallows the error, .always() does not.
Catch "swallows" errors by design. Unless you re throw. chaining another then has no effect on the behavior of a previous catch.
Right, but in the context of the OP's question you'd need the second .then() to mirror what .always() is doing.
The point is, there is no way to do .catch().then() and throw the error unless you do some hideous type checking hack cludge. Hence the need for .always().
The point is, there is no way to do .catch().then() and throw the error unless you do some hideous type checking hack cludge. Hence the need for .always().
Yea, the `catch` would probably have to set an 'errors' object on the response. The following `then` would then decide whether or not to throw an error based on that. Not pretty.
Also, I think `finally` makes your code easier to read. I always put the same kind of cleanup logic in there, everyone on the team knows what to expect in that block.
Also, I think `finally` makes your code easier to read. I always put the same kind of cleanup logic in there, everyone on the team knows what to expect in that block.
If you are returning that promise, you'll need to handle both then and catch so the caller can chain their own catch.
It kind of drives me nuts that this wasn't there to begin with. It seems like it was a standard part of most promises before they were standardized, but now all promise code will either need to ship with a finally shim or avoid finally for the next X years.
I do not undetstand the async example. What is the difference between
Other than that, this is great. But I don't understand the async/await version
try {
const response = await fetch(url);
const text = await response.text();
element.textContent = text;
} catch (error) {
element.textContent = error.message;
} finally {
hideLoadingSpinner();
}
try {
const response = await fetch(url);
const text = await response.text();
element.textContent = text;
} catch (error) {
element.textContent = error.message;
}
hideLoadingSpinner();
Other than that, this is great. But I don't understand the async/await version
In this case, if the error object is undefined/null, then error.messsage throws a TypeError, and the spinner is not hidden.
In general the finally { ... } block is useful because it is guaranteed to execute after the try/catch (if the program has not exited), where as the next line after the try/catch is not, e.g., the try/catch returns, or the catch block throws.
In general the finally { ... } block is useful because it is guaranteed to execute after the try/catch (if the program has not exited), where as the next line after the try/catch is not, e.g., the try/catch returns, or the catch block throws.
Example:
(()=>{try {return 42} finally {console.log('you will see this')}})()
The fn body returns 3, but also the "finally" executes first and you get the console.log. Same with:
(()=>{try {throw 42} finally {console.log('you will see this')}})()
(()=>{try {return 42} finally {console.log('you will see this')}})()
The fn body returns 3, but also the "finally" executes first and you get the console.log. Same with:
(()=>{try {throw 42} finally {console.log('you will see this')}})()
If that's what the example is showing, then it's just obscuring two unrelated try/catch blocks. One for the outcome of the request, and one for the uncertainty of the element reference.
[deleted]
If "element.textContent = error.message" throws an error, "hideLoadingSpinner()" won't get called (in the second example).
[deleted]
If "element" is undefined or null, the catch clause will raise an exception. In the first example, hideLoadingSpinner() will be called anyway, while in the second one it won't.
Finally blocks ensure code executes even on exception. In the second example hideLoadSpinner will never get called if you hit the catch block
incorrect
try {
throw new Error("catch me !"); // force try to fail
} catch (catchedError) {
console.log("inside catch");
// throw new Error("hmm");
} finally {
// always executed
console.log("inside finally");
}
// always executed
console.log("after try catch finally");
That's wrong- if the catch block runs without throwing any exceptions of its own then hideLoadSpinner will be called.
> Since async and await are strictly better, my recommendation remains to use them instead of vanilla promises
Let's not assume that polyfills are free. As far as I can tell [0], you need two Babel transforms to enable support across browsers, with the generator polyfill running you about 20kb.
[0] https://babeljs.io/docs/plugins/preset-es2017/
Let's not assume that polyfills are free. As far as I can tell [0], you need two Babel transforms to enable support across browsers, with the generator polyfill running you about 20kb.
[0] https://babeljs.io/docs/plugins/preset-es2017/
The article that the author links in that sentence goes into more depth; it claims that async/await is better in part because V8 can optimize it better than it can Promises. In other words, async/await is better than Promises, provided that you are not using polyfills. He isn't assuming polyfills are free, he is assuming that you don't need them (or that you can pull them out of your bundle over time)
I'm shocked that `.finally` wasn't part of the standard in the first place. Every promise library I've used (angular 1's $q and bluebird mostly) has had a finally method.
Better late than never, I suppose.
Better late than never, I suppose.
I don’t really get JavaScript. Isn’t this type of try/catch/finally method available on almost every other language? Is JavaScript behind the times or is this just not a common use-case?
Personally I like the “defer” method, where closing actions can be clear and front-loaded in the function definition.
Personally I like the “defer” method, where closing actions can be clear and front-loaded in the function definition.
JavaScript invented a new concurrency model which IMHO is worse than the invention of 'goto', by putting async mechanisms on the callee side:
`result=mayBePromiseOrResultWhoKnows()`
instead of
`go nowThisSyncMethodIsAsync()`
`result=mayBePromiseOrResultWhoKnows()`
instead of
`go nowThisSyncMethodIsAsync()`
JS didn't invent Promises/Futures nor did it invent Async/Await.
mostly true, but in which other language can you call async functions which you expect to be synchronous?
Not sure what you mean, do you mean what other language has "await"? Many.
[deleted]
Despite the downvoting this is spot on. File in the (very large, now bulging) "What were they thinking??" file.
No, the caller has control.
result = await maybePromiseWhoCaresIUsedAwait();
result = await 3;ok and to be safe you
```
await every()
await freakin()
await function()
```
?
Or you may end up with obscure bugs, when you expect a sync method or worse, when a sync method changes to async in the next api version(happened in real world!)
Or you may end up with obscure bugs, when you expect a sync method or worse, when a sync method changes to async in the next api version(happened in real world!)
I'm not aware of any programming language where it is safe to use a function's return value without knowing what the return value is. This seems unrelated to async/await, if you are calling functions that are returning things other than what you expect, you are pretty much screwed.
No in typed language, this is not a problem because the compiler will refuse to compile. For uni-typed languages async/await is not the right model imho.
Again, this is unrelated to async/await. Normal functions might return a number or an object or undefined or whatever. Since JavaScript is a dynamic language it is unsafe to call a function without either 1) Trusting that the function returns what its API says it should return or 2) Checking the return type and acting appropriately.
So, the grandparent's complaint is about JavaScript being a dynamic language, async/await doesn't fix this issue or make it any worse.
So, the grandparent's complaint is about JavaScript being a dynamic language, async/await doesn't fix this issue or make it any worse.
grandpa here. position accepted.
JavaScript does have a try / catch / finally in their exception handling. This update is for Promises which are a method of managing asynchronous code.
[deleted]
What effect will .finally(...).finally(...) have ...?
I suppose it will simply add two side-effects to the last link in the promise chain:
$ node --harmony_promise_finally -e '
Promise
.resolve()
.finally(() => console.log("foo"))
.finally(() => console.log("bar"));
'
foo
barmatt_wulfeck(1)
Just use bluebird
Please don't. According to the docs Bluebird is 17.76KB gzipped. With extensive Promise support in browsers that's a total waste of bandwidth and parse time.
Comparing bluebird and promises is like comparing squares to rectangles. It's a superset. One benefit of bluebird is having specific catch blocks for specific types of errors. You can have certain errors handled by the catch while other errors bubble through. This is also possible (and cleaner) with async/await though. Bluebird also adds a bunch of operators for racing promises a d and polyfills for other things that might not be available in your runtime. I'm not saying to use bluebird, I definitely prefer native implementation, but there are still contrived use cases for bluebird
Sure, but don't "just use Bluebird", as the OP said, in every situation. If you require the extra features of Bluebird, use Bluebird. But if you're just handling simple Promises, it's a waste.
Perhaps I was too terse in my comment and earned myself down votes.
Realistically, if you are shipping software in the real world where it could run on older browsers, you do need to use something like bluebird just to get uniform support. Not to mention things like maps/each/joins/timeouts that you will likely need for anything non-trivial.
Realistically, if you are shipping software in the real world where it could run on older browsers, you do need to use something like bluebird just to get uniform support. Not to mention things like maps/each/joins/timeouts that you will likely need for anything non-trivial.
Not really the ideal solution in a world where people have libraries that return promises and other libraries that operate on promises.
It's really easy with Bluebird to assimilate promises from other libraries, though. Right now, I still think it's best to use Bluebird from the start in a new project than to use native promises. They're faster, have better error stack traces, and more capabilities.
[1]: https://github.com/tc39/proposal-promise-finally [2]: https://github.com/tc39/proposals/blob/master/README.md [3]: https://tc39.github.io/process-document/