Repository navigation
Better error and quick fix for missing await #30646
Description
Activity
- changed the title
[-]Better error and quick fix[/-][+]Better error and quick fix for missing await[/+]on Mar 29, 2019 Ugh, realized html ate a
<T>above. The request should hopefully be more clear now.It's funny because I filed #22923 but not this I guess?
Another suggestion related to this one is the opposite: When there's "await" on things that are not Promises.
const calculateSum = (a: number, b: number) => a + b; async function someAsyncFn() { // ... const result = await calculateSum(a, b); // ... }
Those are definitely not errors, but I think it helps on readability if synchronous stuff is kept in a synchronous way.
Keep in mind that in casecalculateSumreturnsnumber | Promise<number>then this warning shouldn't show up.I'm really not sure if this can/should be added into this issue - For one part it feels closely related (using or not using await on promises) but on the other hand the original issue is tackling something that can potentially lead to errors whereas this one is just.... style.
Yes, now I'm more convinced this shouldn't be here.
Reacted by Abraham White, Andrew Branch, Ghislain B., Maciej Bukowski, Daniel, a1300 and kpietraszkoVictor Oliva (@voliva) Since most of the legwork should already be done at that point i see no reson to not add this.
Another suggestion related to this one is the opposite: When there's "await" on things that are not Promises.
const calculateSum = (a: number, b: number) => a + b; async function someAsyncFn() { // ... const result = await calculateSum(a, b); // ... }
Personally I would prefer to see a warning (or an error) on the
const result = await calculateSum(a, b);telling the user that theawaitis unnecessary since TypeScript already knows, by inference, that the outcome of that call is synchronous and there is nothing toawait. That would push the user to cleanup his code and remove the unnecessaryasync/awaitall together.Reacted by movedoa, Toni Villena, Daniel, a1300, Flavio Vilante, Jessica Wood and kpietraszkoReacted by Flavio VilanteWould a missing-await from an expression-statement also be in-scope? For example:
foo(); // foo: () => Promise<void>
Or is that a whole different class of detectable problems?
Antoine Latter (@aslatter) it’s perfectly well detectable, but unlike the other cases mentioned here, it’s not an error. It’s possibly something we could add a suggestion diagnostic for (like unnecessary await at #32363), but I think it’s even less clear than the unnecessary await case that it’s a mistake. It could very well be a “fire and forget” Promise for something that needn’t interfere with the primary control flow path of the program and doesn’t resolve to anything that you care to observe, e.g. firing a telemetry request or setting something non-critical in a Redis cache. You should probably still have a
.catchin cases like that to avoid unhandled rejections, but I believe I’ve seen linter rules that look for that kind of thing exactly.That said, it is extremely easy to introduce hard-to-find bugs by writing exactly that when you did mean to await it, so I think a suggestion might be nice.
Reacted by Antoine Latter, six, Narayana R and Tim Schmelter
Search Terms
missing await error refactoring
Suggestion
Missing an
awaitcan cause some confusion especially for people who haven't used async/await before. A helpful error message when you have a Promise<T> instead of T that suggests maybe an await is missing might help address this. There are at least a few common cases this comes up:A quick fix could also be considered. When in an async function and an error such as above appears, a quick fix that adds an await before the source of the promise within that function.
Use Cases
It helps people realize when they need an await.
Checklist
My suggestion meets these guidelines: