c# async void vs task: Key Differences

In C#, the return type of an async method determines how errors propagate and whether callers can await the operation. The choice between c# async void vs task is not stylistic; it changes runtime behavior in ways that can crash an application or silently swallow exceptions.

The Core Difference: Return Type and Awaitability

An async Task method returns a Task that represents the ongoing operation. Callers can await that task, inspect its status, and observe exceptions when the task completes. An async void method returns nothing; it is fire-and-forget from the caller's perspective. The caller cannot await it, cannot catch exceptions from it, and has no way to know when it finishes.

public async Task<int> FetchValueAsync()
{
    await Task.Delay(100);
    return 42;
}

public async void FireAndForget()
{
    await Task.Delay(100);
    // No return value, caller cannot await
}

Because async void does not return a task, the compiler does not generate a state machine that can be awaited. The method starts executing synchronously until the first await, then returns control to the caller. Any subsequent work happens on the synchronization context, but the caller has no handle to it.

How Exceptions Behave Differently

Exceptions thrown inside an async Task method are captured by the returned Task. When you await that task, the exception is rethrown at the await point, allowing normal try/catch handling. If you never await the task, the exception is still captured, but it may be observed later via Task.WhenAll or Task.Wait.

With async void, exceptions are not captured in a task. Instead, they are raised on the synchronization context that was current when the method started. In a UI application, this typically means the exception is delivered to the application's DispatcherUnhandledException or UnobservedTaskException handler. In ASP.NET Core, there is no synchronization context, so the exception may be posted to the thread pool and can crash the process if unhandled.

public async Task<int> DivideAsync(int a, int b)
{
    await Task.Yield();
    return a / b; // DivideByZeroException captured in Task
}

public async void RaiseException()
{
    await Task.Yield();
    throw new InvalidOperationException("No task to capture this");
}

If you call RaiseException() without a global exception handler, the exception propagates to the thread pool and may terminate the application. This is the primary reason async void is dangerous outside event handlers.

Why async Task Is Required for Awaitability

Any method that returns async void cannot be awaited. This means the caller cannot sequence operations after it completes, cannot propagate errors, and cannot cancel it cooperatively. In contrast, async Task gives the caller full control: you can await, Task.WhenAny, Task.WhenAll, or pass it to other methods that accept Task.

public async Task ProcessAsync()
{
    await Task.Delay(100);
}

public async void ProcessVoid()
{
    await Task.Delay(100);
}

public async Task CallerAsync()
{
    await ProcessAsync(); // Works
    // await ProcessVoid(); // Compiler error: cannot await void
}

The inability to await async void also breaks exception handling at the call site. Even if you wrap the call in a try/catch, the compiler will not allow it because there is no task to observe. This forces developers to rely on global handlers, which is fragile.

The Only Acceptable Use Case: Event Handlers

Event handlers in C# have a signature that returns void. The .NET event pattern requires void for most events, such as button clicks or timer ticks. When you need to call await inside an event handler, you must declare it as async void because the delegate type does not allow Task.

button.Click += async (sender, e) =>
{
    await LoadDataAsync();
    UpdateUI();
};

This is the one scenario where async void is the only option. The event system does not await the handler, so the method is inherently fire-and-forget. The risk of unhandled exceptions remains, so you must add a try/catch inside the handler to prevent application crashes.

Handling Errors in async void Safely

If you must use async void for an event handler, wrap the entire body in a try/catch and handle the exception explicitly. This prevents the exception from escaping to the synchronization context and crashing the app.

private async void OnButtonClick(object sender, EventArgs e)
{
    try
    {
        await LoadDataAsync();
        UpdateUI();
    }
    catch (Exception ex)
    {
        // Log the exception and show a user-friendly message
        Logger.LogError(ex, "Failed to load data");
        statusLabel.Text = "Load failed";
    }
}

This pattern is acceptable because the event handler is the boundary where the exception can be handled locally. For any other method, prefer async Task and let the caller decide how to handle errors.

Testing and Maintainability Concerns

async void methods are difficult to unit test because the test runner cannot await them. A test that calls an async void method may finish before the asynchronous work completes, leading to flaky tests or false positives. With async Task, you can simply await the method in your test and assert on the result or exception.

[Fact]
public async Task FetchValue_ReturnsExpected()
{
    var result = await _service.FetchValueAsync();
    Assert.Equal(42, result);
}

If FetchValueAsync were async void, you would need to add delays or use Task.Delay to wait for completion, which is unreliable. The maintainability benefit of async Task extends beyond tests: it makes the method composable, allows cancellation tokens, and gives callers a clear contract for completion and failure.

Decision Guidance: When to Use Each

Use async Task for any method that performs asynchronous work and is not an event handler. This includes public APIs, service methods, and helper functions. Use async void only when the method is an event handler and the delegate signature forces void.

If you are writing a method that returns a value, always use async Task<T>. If the method returns no value, use async Task. Reserve async void for the rare event handler case, and even then, handle exceptions inside the method to avoid crashing the application.