Awaiting last method call

Question

A few posts on stack overflow have suggested the following:

Any async method where you have a single await expression awaiting a Task or Task < T >, right at the end of the method with no further processing, would be better off being written without using async/await.

Architecture for async/await

Await or Return

Is this advice just for particular circumstances? On a web server, isn't one of the main reasons to use async/await, being that while awaiting something like the UpdateDataAsync method below, the Thread will return to the ThreadPool, allowing the server to work on other requests?

Should SaveDataAsync await that DB update call given it's the last call in the method?

public async Task WorkWithDataAsync(Data data)
{
    ManipulateData(data);
    await SaveDataAsync(data);
    await SendDataSomewhereAsync(data);
}

public async Task SaveDataAsync(Data data)
{
    FixData(data);
    await DBConnection.UpdateDataAsync(data);
}

Also, given you don't know where SaveDataAsync will be used, making it synchronous would hurt a method like WorkWithDataAsync would it not?

score 7 · Accepted Answer · answered Apr 14 '15 at 18:16

7

Removing the await and just returning the Task doesn't make the method synchronous. await is a tool that makes it easier to make a method asynchronous. It's not the only way to make a method asynchronous. It's there because it allows you to add continuations to task much more easily than you could without it, but in the method that you've shown you're not actually leveraging the await keyword to accomplish anything and as such you can remove it and have the code simply function identically.

(Note that technically the semantics of exceptions will have been slightly changed by removing async; thrown exceptions will be thrown from the method, not wrapped in the returned Task, if it matters to you. As far as any caller is concerned, this is the only observable difference.)

answered Apr 14 '15 at 18:16

Servy

202,030
26
332
449

I see. So essentially, fire and forget methods don't actually need to be marked as `await` given nothing immediately relies on their completion? – Cuthbert Apr 14 '15 at 18:21
It's not a fire and forget method, as it returns a `Task`. But yes, as the task returned from the method you're writing and the `Task` returned from the method you're calling should both complete at the same time, with the same result, you might as well just return that task, rather than creating a new task to wrap it that does nothing but propagate out the same value. Were you doing something more interesting than "nothing" in the continuation of that task, `await` might add value. – Servy Apr 14 '15 at 18:23

score 3 · Answer 2 · answered Apr 14 '15 at 18:17

Writing these methods without the async-await keywords doesn't make them synchronous.

The idea is to return the task directly instead of having the overhead of generating the state machine.

The actual difference is about exception handling. An async method encapsulates exceptions inside the returned task while a simple task returning method doesn't.

If for example FixData throws an exception it will be captured in an async method but directly thrown in a simple task returning one. Both options would be equally asynchronous.

Awaiting last method call

2 Answers2