async/await - when to return a Task vs void?

Question

Under what scenarios would one want to use

public async Task AsyncMethod(int num)

instead of

public async void AsyncMethod(int num)

The only scenario that I can think of is if you need the task to be able to track its progress.

Additionally, in the following method, are the async and await keywords unnecessary?

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

Note that async methods should always be suffixed with the name Async.Example Foo() would become FooAsync(). — Fred
@Fred Mostly, but not always. This is just the convention and the accepted exceptions to this convention are with event based classes or interface contracts, see MSDN. For example, you shouldn’t rename common event handlers, such as Button1_Click. — Ben
Just a note you shouldn't using Thread.Sleep with your tasks you should await Task.Delay(num) instead — Bob Vale
@fred I dont agree with this, IMO adding an async suffix should only be used when you are providing an interface with both sync and async options. Smurf naming things with async when there is only one intent is pointless. Case in point Task.Delay is not Task.AsyncDelay as all the methods on task are Async — Not loved
I had an interesting issue this morning with a webapi 2 controller method, it was declared as async void instead async Task. The method crashed because it was using an Entity Framework context object declared as a member of the controller was disposed before the method finished to execute. The framework disposed the controller before its method finished to execute. I changed the method to async Task and it worked. — costa

Unknown Unknown · Accepted Answer · 2012-08-27T14:53:45

Normally, you would want to return a Task. The main exception should be when you need to have a void return type (for events). If there's no reason to disallow having the caller await your task, why disallow it?
async methods that return void are special in another aspect: they represent top-level async operations, and have additional rules that come into play when your task returns an exception. The easiest way is to show the difference is with an example:

static async void f()
{
    await h();
}

static async Task g()
{
    await h();
}

static async Task h()
{
    throw new NotImplementedException();
}

private void button1_Click(object sender, EventArgs e)
{
    f();
}

private void button2_Click(object sender, EventArgs e)
{
    g();
}

private void button3_Click(object sender, EventArgs e)
{
    GC.Collect();
}

f's exception is always "observed". An exception that leaves a top-level asynchronous method is simply treated like any other unhandled exception. g's exception is never observed. When the garbage collector comes to clean up the task, it sees that the task resulted in an exception, and nobody handled the exception. When that happens, the TaskScheduler.UnobservedTaskException handler runs. You should never let this happen. To use your example,

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

Yes, use async and await here, they make sure your method still works correctly if an exception is thrown.

For more information see: https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming

async/await - when to return a Task vs void?

6 Answers