Introduction

async void methods are generally discouraged because callers cannot await them and exceptions escape differently. There are still valid use cases, primarily event handlers where framework signatures require void. Outside those cases, Task-returning methods are almost always safer.

Reliable implementation guidance should survive maintenance and incident pressure, not only pass quick local checks. Explicit assumptions and validation boundaries make behavior predictable over time.

Core Sections

1. Use async void only for event handlers

UI and event frameworks often require void signatures. In these cases, async void is acceptable with explicit exception handling.

1private async void SaveButton_Click(object sender, EventArgs e)
2{
3    try
4    {
5        await SaveAsync();
6    }
7    catch (Exception ex)
8    {
9        _logger.LogError(ex, "Save failed");
10    }
11}

Build from a minimal baseline and confirm expected success path before adding complexity. This short feedback loop reduces debugging cost and improves review quality.

2. Return Task everywhere else

For services, commands, and reusable methods, return Task so callers can await completion, coordinate cancellation, and handle exceptions predictably.

1public async Task SaveAsync()
2{
3    await repository.FlushAsync();
4}
5
6public async Task HandleRequestAsync()
7{
8    await SaveAsync();
9}

After baseline correctness, harden around edge conditions and error semantics. Clear failure handling is essential for safe integration with surrounding systems.

3. Make exception flow observable

Unhandled exceptions in async void can crash process contexts differently than task-based methods. Keep boundaries explicit and log failures.

Add representative tests for normal, malformed, and dependency-failure scenarios so regressions are detected quickly in CI. Keep these tests deterministic and aligned with real usage patterns.

Operational readiness also includes ownership clarity, focused telemetry, and rollback planning. Teams recover faster when escalation paths and reversion procedures are defined before release.

Document runbook steps near implementation and refresh them when behavior changes. Current notes reduce repeated investigation and improve handoff quality across contributors.

A complete engineering recommendation includes explicit contracts for inputs, outputs, and failure semantics. Document which errors are retriable, which should fail fast, and what callers are expected to do after failure. Clear contracts prevent adjacent modules from inventing inconsistent assumptions that later create hard-to-diagnose integration bugs.

Validation should cover realistic usage, not only toy examples. Include one production-like scenario, one malformed-input case, and one dependency-failure case with deterministic assertions. Keep these checks in CI so every change validates the same assumptions. Repeatable automation is the most reliable way to catch regressions introduced by refactoring or dependency updates.

Observability should be focused on outcomes that matter. Log important branch decisions, include identifiers for traceability, and track metrics tied to user impact such as latency, error rates, and retry behavior. Focused telemetry helps teams separate code defects from environment drift quickly during incident response.

Release safety requires explicit rollback and fallback design. Feature flags, staged rollout, and validated reversion steps can prevent prolonged outages when assumptions fail under real traffic. Recovery planning should be treated as normal engineering work and rehearsed periodically.

Keep concise runbook notes near implementation and update them when behavior changes. Current documentation improves onboarding and reduces repeated investigation cycles during on-call handoffs.

Review post-release metrics against baseline values and record outcomes so future changes can rely on measured evidence.

Capture decisions on async method boundaries in code review notes to keep future changes aligned with agreed error-handling policy.

Common Pitfalls

• Using async void in library APIs that need caller coordination.
• Assuming exceptions from async void behave like task exceptions.
• Starting fire-and-forget work without supervision or logging.
• Ignoring cancellation path design in long-running async operations.
• Converting all methods to async void for convenience.

Summary

• Restrict async void to framework-required event handlers.
• Use Task return types for awaitable business logic.
• Handle and log exceptions explicitly in async void handlers.
• Keep cancellation and completion semantics observable.