Confusion regarding VSTHRD100 and VSTHRD110 for event handlers

[prlcutting]

VSTHRD100 Avoid async void methods suggests that async void should be avoided, and to use the following pattern instead:

private void HandleEvent(object sender, EventArgs e)
{
    _ = joinableTaskFactory.RunAsync(async () =>
    {
       // async code
    });
}

Note the use of the discard for the JoinableTask returned from the RunAsync method. If the discard is removed, it produces VSTHRD110 Observe result of async calls, which makes sense. What makes it "okay" to use a discard here to silence VSTHRD110?

Either way (discard or no discard), doesn't this mean that any exceptions will go unobserved, and will (eventually) result in a UnobservedTaskException at some indeterminate time in the future whenever a garbage collection occurs?

private void HandleEvent(object sender, EventArgs e)
{
    // Task is not awaited, so exception is not observed.
    _joinableTaskFactory.RunAsync(async () =>
    {
        // Task is awaited, so exception is observed.
        // It "rolls up" to the outer Task.
        await ThrowExceptionAsync();
    });
}

In the above scenario, when ThrowExceptionAsync throws an exception, it will go unobserved. That seems problematic. Is this "less bad" than using async void where the exception is immediately observed, at the expense of crashing the application if not handled I guess?

Why does VSTHRD100 Avoid async void methods suggest using JoinableTaskFactory.RunAsync rather than JoinableTaskFactory.Run? The latter seems like a more natural fit for a non-async method like an event handler, with the caveat that we've found we've sometimes run into deadlock situations using it with more complex code.

Also, VSTHRD100 Avoid async void methods suggests referring to Async/Await - Best Practices in Asynchronous Programming by Stephen Cleary which seems to directly contradict VSTHRD100, in that event handlers are an exception to the rule of "avoid async void", and that you should use async void for them (generally). This is confusing.

I guess I'm fumbling around somewhat and trying to develop an understanding of what the best practices are so that I can communicate them to my team, and I'm finding I'm chasing my tail a bit with some of the analyzers, and the documentation is in some cases confusing/contradictory.

In another discussion it was mentioned that for new WPF apps, JoinableTaskFactory shouldn't be needed because you should be async from the start. While a worthy goal, I'm not sure how you fully achieve that when the language and technology push/force you into anti-patterns, e.g., event handlers that require a void signature, WPF requiring updates to happen on the main UI thread, etc.

Any advice would be appreciated, thanks.

In case it helps, I've included a small, crude WPF app using .NET 8 that demonstrates various scenarios for event handlers and exception handling, some of which are discussed above. Note that you'll have to comment out all scenarios but one to run it.

MainWindow.xaml

<Window
    x:Class="JoinableTaskFactoryRunAsync.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:local="clr-namespace:JoinableTaskFactoryRunAsync"
    mc:Ignorable="d"
    Title="MainWindow"
    WindowStartupLocation="CenterScreen"
    Height="450"
    Width="800">

    <Grid
        Margin="10">

        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="20"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>

        <StackPanel
            Grid.Row="0"
            Orientation="Vertical"
            VerticalAlignment="Center">

            <Button
                x:Name="ThrowExceptionButton"
                Content="Throw exception"
                Width="120"
                Height="30"
                Margin="0,0,0,20"/>

            <Button
                x:Name="GCCollectButton"
                Content="GC.Collect"
                Width="120"
                Height="30"/>
        </StackPanel>

        <TextBox
            Grid.Row="2"
            x:Name="OutputTextBlock"
            IsReadOnly="True"
            TextWrapping="Wrap"
            ScrollViewer.HorizontalScrollBarVisibility="Disabled"
            ScrollViewer.VerticalScrollBarVisibility="Auto"/>
    </Grid>
</Window>

MainWindow.xaml.cs

using System;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Threading;
using Microsoft.VisualStudio.Threading;

namespace JoinableTaskFactoryRunAsync;

public partial class MainWindow : Window
{
    private static readonly JoinableTaskContext _joinableTaskContext = new();

    private readonly JoinableTaskFactory _joinableTaskFactory =
        _joinableTaskContext.Factory;

    public MainWindow()
    {
        InitializeComponent();

        ThrowExceptionButton.Click +=
            OnThrowExceptionButtonClick;

        GCCollectButton.Click +=
            OnGCCollectButtonClick;

        Application.Current.Dispatcher.UnhandledException +=
            OnDispatcherUnhandledException;

        TaskScheduler.UnobservedTaskException +=
            OnTaskSchedulerUnobservedTaskException;

        AppDomain.CurrentDomain.UnhandledException +=
            OnCurrentDomainUnhandledException;
    }

    // Scenario 1: CS4014: Normal void event handler. Task not awaited.
    private void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // Task is not awaited, so exception is not observed.
        ThrowExceptionAsync();
    }

    // Scenario 2: VSTHRD100: async void event handler.
    private async void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // Task is awaited, so exception is observed.
        await ThrowExceptionAsync();
    }

    // Scenario 3: JTF.Run.
    private void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        _joinableTaskFactory.Run(async () =>
        {
            // Task is awaited, so exception is observed.
            await ThrowExceptionAsync();
        });
    }

    // Scenario 4: JTF.RunAsync w/o discard. Task not awaited.
    private void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // Task is not awaited, so exception is not observed.
        _joinableTaskFactory.RunAsync(async () =>
        {
            // Task is awaited, so exception is observed.
            await ThrowExceptionAsync();
        });
    }

    // Scenario 5: JTF.RunAsync w/ discard. Task not awaited.
    private void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // Task is not awaited, so exception is not observed.
        _ = _joinableTaskFactory.RunAsync(async () =>
        {
            // Task is awaited, so exception is observed.
            await ThrowExceptionAsync();
        });
    }

    // Scenario 6: VSTHRD100: async void event handler.
    // JTF.RunAsync w/ Task variable. Task is awaited and exception handled.
    private async void OnThrowExceptionButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // Task is not awaited, so exception is not observed.
        var task = _joinableTaskFactory.RunAsync(async () =>
        {
            // Task is awaited, so exception is observed.
            await ThrowExceptionAsync();
        });

        try
        {
            // Task is awaited, so exception is observed.
            await task;
        }
        catch (InvalidOperationException ex)
        {
            await ProcessExceptionAsync(
                ex,
                nameof(InvalidOperationException));
        }
    }

    private void OnGCCollectButtonClick(
        object sender,
        RoutedEventArgs e)
    {
        // This will force any unobserved task exceptions to be rethrown by the
        // finalizer thread. The TaskScheduler.UnobservedTaskException event
        // will be raised.
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }

    private void OnDispatcherUnhandledException(
        object sender,
        DispatcherUnhandledExceptionEventArgs e)
    {
        ProcessException(
            e.Exception,
            nameof(Application.Current.Dispatcher.UnhandledException));

        e.Handled = true;
    }

    private void OnTaskSchedulerUnobservedTaskException(
        object? sender,
        UnobservedTaskExceptionEventArgs e)
    {
        ProcessException(
            e.Exception,
            nameof(TaskScheduler.UnobservedTaskException));

        e.SetObserved();
    }

    private void OnCurrentDomainUnhandledException(
        object sender,
        UnhandledExceptionEventArgs e)
    {
        ProcessException(
            (Exception)e.ExceptionObject,
            nameof(AppDomain.CurrentDomain.UnhandledException));
    }

    private void ProcessException(
        Exception ex,
        string source)
    {
        _ = _joinableTaskFactory.RunAsync(async () =>
        {
            await ProcessExceptionAsync(ex, source);
        });
    }

    private async Task ProcessExceptionAsync(
        Exception ex,
        string source)
    {
        await _joinableTaskFactory.SwitchToMainThreadAsync();

        OutputTextBlock.Text = $"{OutputTextBlock.Text}\n{source}\n\n{ex}".Trim();
    }

    private async Task ThrowExceptionAsync()
    {
        OutputTextBlock.Text = string.Empty;

        await Task.Yield().ConfigureAwait(false);
        throw new InvalidOperationException("Boom!");
    }
}

[andrew-dulac-dnv]

I'm equally confused about these async patterns - some clarification would be great.

The documentation feels like it's written from different perspectives that never got reconciled:

• Analyzer rules seem focused on avoiding deadlocks
• Blog posts focus on proper exception propagation
• Microsoft docs seem to change approach depending on the technology (WPF vs WinForms vs ASP.NET)

What would really help is a clear decision tree from the team:

• When is async void actually appropriate?
• When should we use JTF.RunAsync with discards?
• Are there specific scenarios where one approach is clearly better?
• What's the recommended way to handle exceptions in each case?

Even if there's no perfect solution, understanding the tradeoffs would help us make consistent decisions in our codebases rather than oscillating between patterns based on which analyzer warning we're trying to fix that day.

[AArnott]

The docs you mention are literally from "all over the place" so I wouldn't expect them to all agree. :)

Microsoft docs seem to change approach depending on the technology (WPF vs WinForms vs ASP.NET)

WPF and WinForms policies have no reason to disagree, as they have all the relevant bits in common.

ASP.NET has no main thread, but it does use a single threaded SynchronizationContext to try to throttle the resources dedicated to a single web request. That blurs the line somewhat.
ASP.NET Core did away with the SynchronizationContext I believe.
For all things web, the cost of sync blocking on async work is especially high, because it limits scalability, which can raise costs if you have a high traffic web site or service. While JTF can help reduce this scaling problem while sync blocking on async work even in ASP.NET (Core), by far the best way to go is avoid sync blocking code on the web altogether.

When is async void actually appropriate?

When you want your app to crash on failures and/or you already have a try/catch in your async void method so that it never throws unhandled exceptions anyway.

When should we use JTF.RunAsync with discards?

When you don't want to await and you don't want to know about failures either.

What's the recommended way to handle exceptions in each case?

The easiest and by far most common way of dealing with exceptions is to throw them, and catch them in the caller (somewhere lower in the stack).
If the caller doesn't care about the exception, but the callee does, then the callee should either handle them itself, or forward them onto an error handling service in your process that logs them, reports them to the user, or whatever else you want to do.

[AArnott]

What makes it "okay" to use a discard here to silence VSTHRD110?

That's a policy decision you can make.

• async void crashes the app on exceptions thrown from event handlers. If these event handlers are ignorable, you probably don't want the process to crash.
• the discard pattern silences the problem without reporting it. If you have a better way to report it, by all means do something besides discarding it.

will (eventually) result in a UnobservedTaskException at some indeterminate time in the future whenever a garbage collection occurs?

That depends on whether you use JoinableTaskFactory to wrap your async delegate. A JoinableTask will "observe" a faulted task from the delegate passed to it. So you wouldn't get an UnobservedTaskException in that case regardless. And JoinableTaskFactory has no equivalent UnobservedJoinableTaskException.

What concerns you about UnobservedTaskException? .NET Framework 4.0 crashed the process with that, but .NET Framework 4.5+ dropped that behavior and now you only see these if you hook this event.

Why does VSTHRD100 Avoid async void methods suggest using JoinableTaskFactory.RunAsync rather than JoinableTaskFactory.Run?

Because JTF.Run synchronously blocks the calling thread for your async work. That will cause UI delays in your application. And it forces the party raising the event to wait for your handler to do arbitrary work that it presumably does not directly care about.
Generally speaking, event handlers shouldn't do a lot of work. They're getting a notification as a courtesy from the originator of the event. If they have significant work to do, they should schedule that to happen on their own time and return to the caller.

Also, VSTHRD100 Avoid async void methods suggests referring to Async/Await - Best Practices in Asynchronous Programming by Stephen Cleary which seems to directly contradict VSTHRD100, in that event handlers are an exception to the rule of "avoid async void", and that you should use async void for them (generally). This is confusing.

The question of whether it's ok to use async void for event handlers is a contentious one. I see no reason personally to make an exception (no pun intended) for them. Either you want to track work and handle exceptions or you don't. Why should event handlers uniquely crash an application when most async methods (the ones that return Task) merely report back to their caller? Obviously exception handlers are there for a reason. The issue is that C# event wasn't designed with async in mind, so it's a very poor fit. Some folks feel that "that's ok, just use async void" is an acceptable band-aid. I disagree. Either handle the exceptions within the event handler, or swallow them. Don't crash the app IMO.

I guess I'm fumbling around somewhat and trying to develop an understanding of what the best practices are so that I can communicate them to my team, and I'm finding I'm chasing my tail a bit with some of the analyzers, and the documentation is in some cases confusing/contradictory.

These are policy decisions that you will have to make yourself (or with your team). The analyzers are there to support certain policies, but if they don't match the policies you want to adopt, by all means you can disable the ones that conflict with your goals.

In #1144 (comment) it was mentioned that for new WPF apps, JoinableTaskFactory shouldn't be needed because you should be async from the start. While a worthy goal, I'm not sure how you fully achieve that when the language and technology push/force you into anti-patterns, e.g., event handlers that require a void signature, WPF requiring updates to happen on the main UI thread, etc.

In a new WPF app, I would personally strive hard to avoid sync-blocking wherever I could. The hardest point might be on shutdown where you need to save files before exiting and that may be implemented asynchronously. But even then, I've pulled tricks like hiding the main window and allowing the main thread to continue until saving is done in order to avoid using JTF at all.
JTF is awesome, but it's a crutch. And I am reluctant to add it to a new app. It was created in the first place to help bridge the sync and async worlds. Bless you if you don't have to cross that bridge.