Introduction

In C#, an "async action" can mean two related but importantly different things: an asynchronous method or an asynchronous delegate. The main rule is that async work should normally return Task or Task<T>. If you force async logic into Action, you usually end up with async void, which is much harder to compose and test.

Define Async Methods with Task

The usual way to define asynchronous behavior in C# is an async method that returns Task or Task<T>.

1using System;
2using System.Net.Http;
3using System.Threading.Tasks;
4
5public class Downloader
6{
7    private static readonly HttpClient Http = new HttpClient();
8
9    public async Task<string> FetchAsync(string url)
10    {
11        string body = await Http.GetStringAsync(url);
12        return body;
13    }
14}

This is the normal, composable async form. The caller can await it, handle exceptions, or combine it with other tasks.

Prefer Func<Task> over Action for Async Delegates

If you need to store or pass asynchronous behavior as a delegate, use Func<Task> rather than Action.

1using System;
2using System.Threading.Tasks;
3
4Func<Task> work = async () =>
5{
6    await Task.Delay(500);
7    Console.WriteLine("done");
8};
9
10await work();

This works well because the delegate exposes a Task that the caller can await. That keeps the async boundary visible.

Why Action Is Usually the Wrong Choice

Action returns void. If you attach async to a lambda assigned to Action, you create an async void delegate.

1Action bad = async () =>
2{
3    await Task.Delay(500);
4    Console.WriteLine("finished");
5};

This compiles, but it is usually a bad design outside of event handlers. The caller cannot await completion, and exceptions are harder to observe and coordinate.

That is why the more correct async delegate shapes are usually:

• 'Func<Task> for no result'
• 'Func<Task<T>> for a result'

Returning Values from Async Work

When the async operation produces a value, use Task<T>.

1using System;
2using System.Threading.Tasks;
3
4Func<Task<int>> countAsync = async () =>
5{
6    await Task.Delay(200);
7    return 42;
8};
9
10int result = await countAsync();
11Console.WriteLine(result);

This is the async equivalent of using Func<int> instead of Action.

Event Handlers Are the Main Exception

async void is still valid for event handlers because the event signature itself requires void.

1using System;
2using System.Threading.Tasks;
3
4public class ButtonDemo
5{
6    public async void OnClick(object? sender, EventArgs e)
7    {
8        await Task.Delay(300);
9        Console.WriteLine("click handled");
10    }
11}

This is the main case where async void is appropriate. Outside that pattern, prefer Task-returning methods.

Compose Async Actions Cleanly

Once your async action returns Task, composition becomes easy.

1using System;
2using System.Threading.Tasks;
3
4public static async Task RunTwiceAsync(Func<Task> action)
5{
6    await action();
7    await action();
8}
9
10await RunTwiceAsync(async () =>
11{
12    await Task.Delay(100);
13    Console.WriteLine("running");
14});

This is much harder to do correctly if the delegate shape is Action.

Common Pitfalls

A common mistake is assigning async logic to Action and then assuming the caller can wait for it. It cannot, because the delegate returns void.

Another is using async void outside of UI or event-driven scenarios. That makes error handling and coordination significantly harder.

Developers also sometimes mark a method async without any real asynchronous operation inside it. If there is nothing to await, the method probably should not be async at all.

Summary

• Use async Task or async Task<T> for normal asynchronous methods.
• Use Func<Task> or Func<Task<T>> when you need async delegates.
• Avoid Action for async work because it usually forces async void.
• Reserve async void mainly for event handlers.
• 'Task-returning async actions are easier to await, test, combine, and debug.'