Before ES2018, I used to nest an extra then at the end of the promise chain whenever I had to perform any clean up logic that I'd otherwise duplicate in then and catch above, e.g.
new Promise(
(res, rej) => setTimeout(() => rej({}), 1000)
).then(
res => console.log(res)
).catch(
err => console.error(err)
).then(
() => console.log('Finally')
)But now that finally was added on the Promise prototype, I can't see how it's different from the last then in the above approach. The following will produce identical output.
new Promise(
(res, rej) => setTimeout(() => rej({}), 1000)
).then(
res => console.log(res)
).catch(
err => console.error(err)
).finally(
() => console.log('Finally')
)Does finally merely serve a semantic purpose in the native Promise API?
A then callback doesn't execute when the promise is rejected - and that can happen even for a promise returned by a catch invocation: when its callback throws or returns a rejected promise. err => console.error(err) is probably not going to do that, but you never know.
Similarly, I would recommend to favour .then(…, …) over .then(…).catch(…) if you only want to handle errors from the original promise, not from the then callback. I'd write
promise.then(console.log, console.error).finally(() => console.log('Finally'));
The other more or less obvious differences are in the signature: the finally callback doesn't receive any arguments, and the promise that p.finally() returns will fulfill/reject with the same result as p (unless there's an exception or returned rejection in the callback).