Why use async and return await, when you can return Task<T> directly?

Question

Is there any scenario where writing method like this:

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

instead of this:

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

would make sense?

Why use return await construct when you can directly return Task<T> from the inner DoAnotherThingAsync() invocation?

I see code with return await in so many places, I think I might have missed something. But as far as I understand, not using async/await keywords in this case and directly returning the Task would be functionally equivalent. Why add additional overhead of additional await layer?

Cuckoopint

I think the only reason why you see this is because people learn by imitation and generally (if they don't need) they use the most simple solution they can find. So people see that code, use that code, they see it works and from now on, for them, that's the right way to do it... It's no use to await in that case – Caprine

There's at least one important difference: exception propagation. – Pockmark

I dont understand it either, cant comprehend this entire concept at all, doesnt make any sense. From what I learned if a method has a return type, IT MUST have a return keyword, isnt it the rules of C# language? – Ghana

@Ghana the OP's question does have the return statement though? – Mucky

github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/… – Jewel

For anyone obsessed with this question, there is a recent YouTube video by Nick Chapsas here. – Dowery

If DoAnotherThingAsync is written with async/await, then the async/await here is redundant and there's no different in exception propagation. DoAnotherThingAsync already implements the state machine that captures any exceptions thrown and embeds them in the returned Task. The only time you'd want to add async/await here is if the called method DoAnotherThingAsync does not use async/await and may throw exceptions. In that case, an exception could be thrown before the Task is returned, changing the required error handling approach. That's really the only difference. – Caracaraballo

Answer 1

There is one sneaky case when return in normal method and return await in async method behave differently: when combined with using (or, more generally, any return await in a try block).

Consider these two versions of a method:

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

The first method will Dispose() the Foo object as soon as the DoAnotherThingAsync() method returns, which is likely long before it actually completes. This means the first version is probably buggy (because Foo is disposed too soon), while the second version will work fine.

Tequilater

For completeness, in first case you should return foo.DoAnotherThingAsync().ContinueWith(_ => foo.Dispose()); – Vazquez

@Vazquez That wouldn't work, Dispose() returns void. You would need something like return foo.DoAnotherThingAsync().ContinueWith(t -> { foo.Dispose(); return t.Result; });. But I don't know why would you do that when you can use the second option. – Tequilater

@Tequilater You're right, it should be more along the lines of { var task = DoAnotherThingAsync(); task.ContinueWith(_ => foo.Dispose()); return task; }. The use case is pretty simple: if you are on .NET 4.0 (like most), you can still write async code this way which will work nicely called from 4.5 apps. – Vazquez

@Vazquez If you are on .Net 4.0 and you want to write asynchronous code, you should probably use Microsoft.Bcl.Async. And your code disposes of Foo only after the returned Task completes, which I don't like, because it unnecessarily introduces concurrency. – Tequilater

@Tequilater Your code waits until the task is finished too. Also, Microsoft.Bcl.Async is unusable for me due to dependency on KB2468871 and conflicts when using .NET 4.0 async codebase with proper 4.5 async code. – Vazquez

@Tequilater Would it be safe to say to always use async and await to prevent this problem from happening? Because in the first example if the object foo isn't garbage collected and Dispose doesn't prevent DoAnotherThingAsync from finishing then this isn't easily identifiable as an exception isn't thrown. But wouldn't the drawback be that you're always starting a new thread regardless of whether its required or not if we follow this approach?? Apologies if I've misunderstood something. – Lallage

@Lallage Short answer: yes. Longer answer: yes, unless it affects performance in a way that matters to you. Though it's not about starting threads, async doesn't do that. – Tequilater

An analogous case would be lock(someObject){ return await SomeAsyncMethond(); } – Cosper

@JonHanna Fortunately, that doesn't compile. – Tequilater

@Tequilater Ah indeed. And yes, fortunately :) – Cosper

one more thing to be noted is the call stack as mentioned in https://mcmap.net/q/76870/-await-or-task-fromresult – Anther

The return foo.DoAnotherThingAsync(); should check if foo is disposed and throw ObjectDisposedException. and if Foo implements: IAsyncDisposable the await using (var foo = new Foo()) return await foo.DoAnotherThingAsync(); forces you to return await. – Rachaba

Answer 2

If you don't need async (i.e., you can return the Task directly), then don't use async.

There are some situations where return await is useful, like if you have two asynchronous operations to do:

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

For more on async performance, see Stephen Toub's MSDN article and video on the topic.

Update: I've written a blog post that goes into much more detail.

Gayn

Could you add an explanation as to why the await is useful in the second case? Why not do return SecondAwait(intermediate); ? – Yokoyokohama

I have same question as Matt, wouldn't return SecondAwait(intermediate); achieve the goal in that case as well? I think return await is redundant here as well... – Cuckoopint

@MattSmith That wouldn't compile. If you want to use await in the first line, you have to use it in the second one too. – Tequilater

@Tequilater as they just run sequentially, should they be changed to normal calls like var intermediate = First(); return Second(intermediate) to avoid the overhead introduced by paralleling then. The async calls aren't necessary in this case, are they? – Meson

@Meson I'm not sure what “overhead introduced by paralleling them” means, but the async version will use less resources (threads) than your synchronous version. – Tequilater

@Tequilater "That wouldn't compile. If you want to use await in the first line, you have to use it in the second one too." That is not true. The code will both compile and run just fine if you omit the second await and return SecondAwait directly. – Mashie

@TomLint It really doesn't compile. Assuming the return type of SecondAwait is `string, the error message is: "CS4016: Since this is an async method, the return expression must be of type 'string' rather than 'Task<string>'". – Tequilater

@Tequilater You're right. Once you declare the method as 'async', you lose the ability to return a Task directly. I got confused by some code of mine which directly returned the Task from another async method instead of awaiting it. – Mashie

Stephen Cleary would you like to include an excerpt of your Eliding Async and Await blog post as part of this answer? I think that the paragraphs Efficiency, Pitfalls, Using and Exceptions would be helpful here, leaving out the AsyncLocal for being a too rare and specialized scenario. – Dowery

Answer 3

The only reason you'd want to do it is if there is some other await in the earlier code, or if you're in some way manipulating the result before returning it. Another way in which that might be happening is through a try/catch that changes how exceptions are handled. If you aren't doing any of that then you're right, there's no reason to add the overhead of making the method async.

Vladimir

As with Stephen's answer, I don't understand why would return await be necessary (instead of just returning the task of child invocation) even if there is some other await in the earlier code. Could you please provide explanation? – Cuckoopint

@Cuckoopint If you would want to remove async then how would you await the first task? You need to mark the method as async if you want to use any awaits. If the method is marked as async and you have an await earlier in code, then you need to await the second async operation for it to be of the proper type. If you just removed await then it wouldn't compile as the return value wouldn't be of the proper type. Since the method is async the result is always wrapped in a task. – Vladimir

@Servy, I guess the question is, why would we do var result1 = await Task1Async(); return await Task2Async(result1), while we could just do var result1 = await Task1Async(); return Task2Async(result1)? I can't think of any reason, besides handling exceptions possibly thrown by Task2Async in this scope. – Pockmark

@Noseratio Try the two. The first compiles. The second doesn't. The error message will tell you the problem. You won't be returning the proper type. When in an async method you don't return a task, you return the result of the task which will then be wrapped. – Vladimir

@Servy, of course - you're right. In the latter case we would return Task<Type> explicitly, while async dictates to return Type (which the compiler itself would turn into Task<Type>). – Pockmark

@Vladimir You could do: return Task1Async.ContinueWith(task => Task2Async(task.Result)).Unwrap(). While not as clean, you don't have to incur the async overhead if you don't actually need the result of task1 – Argo

@Argo Well sure, async is just syntactic sugar for explicitly wiring up continuations. You don't need async to do anything, but when doing just about any non-trivial asynchronous operation it's dramatically easier to work with. For example, the code you provided doesn't actually propagate errors as you'd want it to, and doing so properly in even more complex situations starts to become quite a lot harder. While you never need async, the situations I describe are where it's adding value to use it. – Vladimir

Answer 4

Another case you may need to await the result is this one:

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

In this case, GetIFooAsync() must await the result of GetFooAsync because the type of T is different between the two methods and Task<Foo> is not directly assignable to Task<IFoo>. But if you await the result, it just becomes Foo which is directly assignable to IFoo. Then the async method just repackages the result inside Task<IFoo> and away you go.

Earshot

Agree, this is really annoying - I believe the underlying cause is that Task<> is invariant. – Gifford

Answer 5

If you won't use return await you could ruin your stack trace while debugging or when it's printed in the logs on exceptions.

When you return the task, the method fulfilled its purpose and it's out of the call stack. When you use return await you're leaving it in the call stack.

For example:

Call stack when using await: A awaiting the task from B => B awaiting the task from C

Call stack when not using await: A awaiting the task from C, which B has returned.

Enchondroma

Here is a good article about this: vkontech.com/… – Monamonachal

Answer 6

Making the otherwise simple "thunk" method async creates an async state machine in memory whereas the non-async one doesn't. While that can often point folks at using the non-async version because it's more efficient (which is true) it also means that in the event of a hang, you have no evidence that that method is involved in the "return/continuation stack" which sometimes makes it more difficult to understand the hang.

So yes, when perf isn't critical (and it usually isn't) I'll throw async on all these thunk methods so that I have the async state machine to help me diagnose hangs later, and also to help ensure that if those thunk methods ever evolve over time, they'll be sure to return faulted tasks instead of throw.

Earshot

Answer 7

This also confuses me and I feel that the previous answers overlooked your actual question:

Why use return await construct when you can directly return Task from the inner DoAnotherThingAsync() invocation?

Well sometimes you actually want a Task<SomeType>, but most time you actually want an instance of SomeType, that is, the result from the task.

From your code:

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

A person unfamiliar with the syntax (me, for example) might think that this method should return a Task<SomeResult>, but since it is marked with async, it means that its actual return type is SomeResult. If you just use return foo.DoAnotherThingAsync(), you'd be returning a Task, which wouldn't compile. The correct way is to return the result of the task, so the return await.

Sprayberry

"actual return type". Eh? async/await isn't changing return types. In your example var task = DoSomethingAsync(); would give you a task, not T – Inveterate

@Shoe I am not sure I understood well the async/await thing. To my understanding, Task task = DoSomethingAsync(), while Something something = await DoSomethingAsync() both work. The first gives you the task proper, while the second, due to the await keyword, gives you the result from the task after it completes. I could, for example, have Task task = DoSomethingAsync(); Something something = await task;. – Sprayberry

Answer 8

Another reason for why you may want to return await: The await syntax lets you avoid hitting a mismatch between Task<T> and ValueTask<T> types. For example, the code below works even though SubTask method returns Task<T> but its caller returns ValueTask<T>.

async Task<T> SubTask()
{
...
}

async ValueTask<T> DoSomething()
{
  await UnimportantTask();
  return await SubTask();
}

If you skip await on the DoSomething() line, you'll get a compiler error CS0029:

Cannot implicitly convert type 'System.Threading.Tasks.Task<BlaBla>' to 'System.Threading.Tasks.ValueTask<BlaBla>'.

You'll get CS0030 too, if you try to explicitly typecast it.

This is .NET Framework, by the way. I can totally foresee a comment saying "that's fixed in .NET hypothetical_version", I haven't tested it. :)

Ancelin

Calling this a conversion is a bit missleading I would say, since it has nothing to do with conversion as far as I understand. What you are doing above is getting the T result from the SubTask and then returning that result, not a task. So T is the same T, there are no any conversions. – Molybdous

@Molybdous Edited it now. How does it look? – Ancelin

Great! Thanks for being proactive :) – Molybdous

Answer 9

This would prevent creating the task state machine that would be created under the hood at compile time. But according to David you should prefer async/await over directly returning Task for these reasons:

• Asynchronous and synchronous exceptions are normalized to always be asynchronous.
• The code is easier to modify (consider adding a using, for example).
• Diagnostics of asynchronous methods are easier (debugging hangs etc).
• Exceptions thrown will be automatically wrapped in the returned Task instead of surprising the caller with an actual exception.
• Async locals will not leak out of async methods. If you set an async local in a non-async method, it will "leak" out of that call.

💡NOTE: There are performance considerations when using an async state machine over directly returning the Task. It's always faster to directly return the Task since it does less work but you end up changing the behavior and potentially losing some of the benefits of the async state machine.

If you really want to break out of the asynchrony, you should know that asynchrony is viral:

Once you go async, all of your callers SHOULD be async, since efforts to be async amount to nothing unless the entire callstack is async. In many cases, being partially async can be worse than being entirely synchronous. Therefore it is best to go all in, and make everything async at once.

Jewel

Answer 10

Another problem with non-await method is sometimes you cannot implicitly cast the return type, especially with Task<IEnumerable<T>>:

async Task<List<string>> GetListAsync(string foo) => new();

// This method works
async Task<IEnumerable<string>> GetMyList() => await GetListAsync("myFoo");

// This won't work
Task<IEnumerable<string>> GetMyListNoAsync() => GetListAsync("myFoo");

The error:

Cannot implicitly convert type 'System.Threading.Tasks.Task<System.Collections.Generic.List>' to 'System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable>'

Spagyric