Beware of “async void” in C#

To make it perfectly clear , "async void" should be replaced with "async Task"

The async stuff is interesting in that akin to generics it has an almost cancerous effect on your code. When you start using them they tends to spread to large parts of your code base if you're not careful.

It's awesome that C# now has such good support for parallelism and asynchronicity... but I remain in the opinion that a lot of this stuff is grafted on to the language and at some point we need to start over from scratch. Already more and more of the code is taken up by crud that should be abstracted away.

Async void methods are for asynchronous event handlers. [1] That's an unfortunate consequence of the way event handlers work in C# (event handlers that return a type don't work well in the language).

Any other use of async void is incorrect; if you see an async void method in any other context, replace it with async Task. (Would be nice if calling an async void method directly threw a compiler warning to make this completely clear.)

[1] https://msdn.microsoft.com/en-us/magazine/jj991977.aspx?f=25...

The article is not strictly correct. A more detailed explanation can be found here: https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Exceptions actually bubble up to the active SynchronizationContext, and won't necessarily kill your process. In ASP.Net, aborting a request on an error is often desired behavior.

Still generally good advice though. Issues arising from accidental async void use are often very tricky to track down, and in my own code I only use it for fire-and-forget-best-effort event handling and run them all in a SynchronizationContext that captures and logs the exceptions.

For completeness, isn't there a third option of ensuring you're catching and handling all exceptions in an async void handler?

   private static async void OnTimerFired(object sender, ElapsedEventArgs args)

   {
	Exception exception = null;
	try
	{
		await Task.Delay(1000);

		// this is NOT going to terminate your process!
		throw new Exception();
	}
	catch (Exception ex)
	{
	  exception = ex;
	}

	if (exception != null)
	{
	  ...
	}
  }

And in C#6 you can await in catch or finally blocks, so this gets even simpler.

You should really just use Rx.NET (http://www.introtorx.com/content/v1.0.10621.0/01_WhyRx.html) if you want async even handling

To be a bit facetious: remember that an unhandled exception in your main program thread will also crash your program.

The article holds a very valuable lesson, though: just because you don't see "Task" doesn't mean that there aren't threads involved. In this way `async void` is deceptive but is certainly not something that is broken or something that you should never use. There is actually a case where an exception in one of these methods will not bring your process down:

    async void button1_Click(object sender, EventArgs e) {
        await Task.Delay(1000);
        throw new Exception("No crash here!");
    }

Why? A lesser known artifact from the .Net 2.0 days. In an unbelievable feat of foresight Microsoft wrote a class called SynchronizationContext[1]. It's a TLS object that defines a way to invoke methods on a well-known target. In the case of the one provided by System.Windows.Forms (which is active in the UI thread) it will dispatch callbacks back onto the main thread. Essentially what is happening with my above code is:

    void button1_Click(object sender, EventArgs e) {
        var sc = SynchronizationContext.Current;
        Task.Delay(1000).GetAwaiter().OnCompleted(() => sc.Send(_ => {
            // Back on the UI thread, thanks SynchronizationContext!
            throw new Exception("No crash here!");
        }, null));
    }

The WindowsSynchronizationContext object (which is what SynchronizationContext.Current will point to on a UI thread) simply has a reference to the dispatcher and calls something similar to Control.Invoke(). This means that the code is re-routed back to the UI thread and because it occurs there you get the standard Windows.Forms error dialog with the option to "Quit" or "Continue" - ultimately preventing a crash. TPL leverages SynchronizationContext which is why this all works. Indeed, the very final example in the article (it looks like Windows.Timer) won't crash with `async void`.

As far as I remember, ASP.Net provides a SynchronizationContext for requests but I am unsure as to how it deals with exceptions (if it does at all). It's implementation specific.

Finally SynchronizationContext can be implemented by you allowing you to also deal with these exceptions in a clean/proper way[2]. Please don't ever do anything along the lines of `SwallowException`. Keep in mind that not everything takes advantage of SynchronizationContext (e.g. Threading.Timer) so it's definitely not a catch-all.

[1]: https://msdn.microsoft.com/en-us/library/system.threading.sy... [2]: https://gist.github.com/jcdickinson/6aa4a09b60bd2469baf5

This is a rough one, because while Microsoft's own docs tell you not to use async void, all of their demo code that I've seen does.

Granted, it's demo code and not production code, but less experienced developers do not always pick up on that.