async void method outside an event handler
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
An async void method cannot be awaited, so callers cannot observe its completion or catch exceptions it throws; an unhandled exception inside one crashes the process instead of faulting a Task. This shape is only conventional for UI/event handlers (which take an EventArgs-shaped parameter); anywhere else it should return async Task.
Why it matters
An async void method cannot be awaited by its caller, so the caller has no way to know when it finishes or to observe an exception it throws. If that method throws an unhandled exception, it is raised directly on the SynchronizationContext (or the thread pool) instead of being captured in a Task, which in most hosts crashes the process rather than failing gracefully. This shape is only safe for UI/event handlers, where the framework is specifically designed to catch it.
How to fix it
Change the method's return type from void to Task (or ValueTask) so exceptions propagate through the returned Task and callers can await it. Leave async void only on methods that are genuinely event handlers (matching the standard (object sender, EventArgs e) signature), since that is the one place the .NET event-invocation model expects it.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo