By sfletche


2017-04-11 17:57:38 8 Comments

I see there is an eslint rule, no-return-await, for disallowing return await.

In the rule's description, it states a return await adds "extra time before the overarching Promise resolves or rejects".

However, when I look at MDN async function docs, the "Simple Example" shows an example containing return await without any description of why this might be a performance problem.

Is return await an actual performance problem as the eslint docs suggest?

And if so, how?

1 comments

@Bergi 2017-05-15 16:59:58

No, there isn't any performance problem. It's just an unnecessary extra operation. It might take a bit longer to execute, but should be hardly noticeable. It's akin to return x+0 instead of return x for an integer x. Or rather, exactly equivalent to the pointless .then(x => x).

It doesn't do actual harm, but I'd consider it bad style and a sign that the author does not fully compre­hend promises and async/await.

However, there's one case where it make an important difference:

try {
    …
    return await …;
} …

await does throw on rejections, and in any case awaits the promise resolution before catch or finally handlers are executed. A plain return would have ignored that.

@TigerBear 2018-08-22 14:43:18

IMO comparing it to return .then(x => x) is a bit harsh. As you pointed out, it is necessary in a try/catch. It would be maybe more like .then((x) => x.data) vs .then(x => x.data). I.E. in cases where you have multiple parameters, the parentheses around x are necessary, otherwise they are optional. I would view this as the same mindset with the debate being: Is it better to be consistent or to minimize?

@Bergi 2018-08-22 18:23:21

@TigerBear No, it's not harsh - it's exactly what is happening there. Writing return await … would be odd, just like await await … would be odd. It works, but is useless.

@TigerBear 2018-08-23 14:56:14

I wouldn't call it useless though since, as you already pointed out, it sometimes has a use, meaning it falls in a different category. Consistent vs Minimal. Similar to parentheses around arrow function parameters

@Bergi 2018-08-24 08:16:17

@TigerBear That's a very different construct that I am not calling useless, and there is no reason to consistently use return await in the different cases. await in a try block is equivalent to .then(x => x, err => …) or .catch(err => …) and is obviously not pointless.

@Mörre 2019-06-22 19:37:39

"I'd consider it bad style and a sign that the author does not fully compre­hend promises" -- Careful with that - you yourself are not aware of zero-cost async stack traces enabled by the await (already in V8 right now). See my comment below the question with the link. Also, with runtimes that don't do that you could use try/catch to build your own full stack trace, potentially valuable for some portions of code (try finding the cause of a problem if the function raising it, e.g. "file not found", is called from many different places and the filename does not help - which function was it?

Related Questions

Sponsored Content

9 Answered Questions

[SOLVED] Why do we need middleware for async flow in Redux?

8 Answered Questions

[SOLVED] Is it not possible to stringify an Error using JSON.stringify?

8 Answered Questions

[SOLVED] Why use Redux over Facebook Flux?

7 Answered Questions

[SOLVED] What is the purpose of "return await" in C#?

1 Answered Questions

async await setstate and returning promises

2 Answered Questions

1 Answered Questions

[SOLVED] async/await vs combining generators and promises?

4 Answered Questions

2 Answered Questions

[SOLVED] async and await not returning to caller as expected

  • 2013-10-07 19:04:52
  • atconway
  • 8757 View
  • 3 Score
  • 2 Answer
  • Tags:   c# async-await

2 Answered Questions

[SOLVED] Using async/await to improve performance

Sponsored Content