696

Under what scenarios would one want to use

public async Task AsyncMethod(int num)

instead of

public async void AsyncMethod(int num)

The only scenario that I can think of is if you need the task to be able to track its progress.

Additionally, in the following method, are the async and await keywords unnecessary?

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}
Boiethios
  • 38,438
  • 19
  • 134
  • 183
user981225
  • 8,762
  • 6
  • 32
  • 41
  • 46
    @Fred Mostly, but not always. This is just the convention and the accepted exceptions to this convention are with event based classes or interface contracts, [see MSDN](https://msdn.microsoft.com/en-us/library/mt674882.aspx#Anchor_7). For example, you shouldn’t rename common event handlers, such as Button1_Click. – Ben Jun 16 '16 at 12:09
  • 17
    Just a note you shouldn't using `Thread.Sleep` with your tasks you should `await Task.Delay(num)` instead – Bob Vale Apr 07 '17 at 11:01
  • 78
    @fred I dont agree with this, IMO adding an async suffix should only be used when you are providing an interface with both sync and async options. Smurf naming things with async when there is only one intent is pointless. Case in point `Task.Delay` is not `Task.AsyncDelay` as all the methods on task are Async – undefined Apr 30 '17 at 23:35
  • 17
    I had an interesting issue this morning with a webapi 2 controller method, it was declared as `async void` instead `async Task`. The method crashed because it was using an Entity Framework context object declared as a member of the controller was disposed before the method finished to execute. The framework disposed the controller before its method finished to execute. I changed the method to async Task and it worked. – boggy May 26 '17 at 17:51
  • 2
    I think [this link](https://msdn.microsoft.com/en-us/magazine/jj991977.aspx) helps. – Milad Jul 03 '17 at 07:53

6 Answers6

548
  1. Normally, you would want to return a Task. The main exception should be when you need to have a void return type (for events). If there's no reason to disallow having the caller await your task, why disallow it?

  2. async methods that return void are special in another aspect: they represent top-level async operations, and have additional rules that come into play when your task returns an exception. The easiest way is to show the difference is with an example:

static async void f()
{
    await h();
}

static async Task g()
{
    await h();
}

static async Task h()
{
    throw new NotImplementedException();
}

private void button1_Click(object sender, EventArgs e)
{
    f();
}

private void button2_Click(object sender, EventArgs e)
{
    g();
}

private void button3_Click(object sender, EventArgs e)
{
    GC.Collect();
}

f's exception is always "observed". An exception that leaves a top-level asynchronous method is simply treated like any other unhandled exception. g's exception is never observed. When the garbage collector comes to clean up the task, it sees that the task resulted in an exception, and nobody handled the exception. When that happens, the TaskScheduler.UnobservedTaskException handler runs. You should never let this happen. To use your example,

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

Yes, use async and await here, they make sure your method still works correctly if an exception is thrown.

For more information see: https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming

Ian Kemp
  • 28,293
  • 19
  • 112
  • 138
  • I agree with your recommendations, but note that in the final release of `async` (VS2012), the exception from `g` will be passed to the `SynchronizationContext`. – Stephen Cleary Aug 27 '12 at 16:06
  • @StephenCleary I have VS2012 installed (the final release, not the RC), and if I call `g`, I don't get the regular unhandled exception dialog box (which based on your comment I understand would happen on your system), and I do see the `UnobservedTaskException` handler run. –  Aug 28 '12 at 06:51
  • 12
    I meant `f` instead of `g` in my comment. The exception from *`f`* is passed to the `SynchronizationContext`. `g` will raise `UnobservedTaskException`, but `UTE` no longer crashes the process if it's not handled. There are some situations where it's acceptable to have "asynchronous exceptions" like this that are ignored. – Stephen Cleary Aug 28 '12 at 13:07
  • @StephenCleary In that case, sure, that is what I meant by "treated like any other unhandled exception", but I could have been more verbose for clarity. As for unobserved exceptions, could you give an example where they are acceptable? –  Aug 28 '12 at 13:22
  • 3
    If you have `WhenAny` with multiple `Task`s resulting in exceptions. You often only have to handle the first one, and you often want to ignore the others. – Stephen Cleary Aug 28 '12 at 13:29
  • 1
    @StephenCleary Thanks, I guess that's a good example, although it depends on the reason you call `WhenAny` in the first place whether it's okay to ignore the other exceptions: the main use case I have for it still ends up awaiting the remaining tasks when any finishes, with or without an exception. –  Aug 28 '12 at 13:41
  • 21
    I'm a little confused as to why you recommend returning a Task instead of void. Like you said, f() will throw and exception but g() will not. Isn't it best to be made aware of these background thread exceptions? – user981225 Aug 28 '12 at 17:41
  • 2
    @user981225 Indeed, but that then becomes the responsibility of g's caller: every method that calls g should be async and use await too. This is a guideline, not a hard rule, you can decide that in your specific program, it's easier to have g return void. –  Aug 28 '12 at 20:12
  • @hvd I don't get why async+await are needed when the method doesn't need the result of the task. Isn't just an overhead? – user3285954 Dec 16 '16 at 13:37
  • @user3285954 The method either needs to take responsibility for any exceptions thrown by the task, for instance by posting them to the synchronisation context (that's what `async void`+`await` does), or it needs to pass the responsibility for exceptions to the caller (that's what `async Task`+`await` does). For the latter, you're right that there is an option to remove `async`/`await`: you can return a `Task` object directly. For the former, that means the method implicitly *does* need the result. Or at least, it needs to know whether the task *has* a result rather than an exception. –  Dec 16 '16 at 13:43
  • @hvd So in the example provided in question async/await are not needed because is the latter. – user3285954 Dec 16 '16 at 17:02
  • @user3285954 If the caller is not set up to pay attention to exceptions, it would be the former, not the latter. It's not 100% clear from the question, but that's how I interpreted it. If it *is* the latter though, don't turn it into `void AsyncMethod2(int num) { Task.Factory.StartNew(() => Thread.Sleep(num)); }` (that's what simply removing `async` and `await`, like the question suggested, would do), but `Task AsyncMethod2(int num) { return Task.Factory.StartNew(() => Thread.Sleep(num)); }` could be fine as long as callers do not discard the result. –  Dec 17 '16 at 01:14
  • @hvd It is clear that Task should be returned, I was only puzzled about why async/await are needed if method doesn't need the result of task. The framework will raise the expections if are not observed by user code, this is one of the major benefits of Task over Thread. With Task it can never happen that an exception is swallowed accidentally, one has to write code for this to happen opposed to Thread where code is needed to handle exceptions otherwise they aren't raised in caller code. – user3285954 Dec 17 '16 at 15:25
  • @user3285954 "The framework will raise the expections if are not observed by user code, this is one of the major benefits of Task over Thread." -- Only through the `TaskScheduler.UnobservedTaskException` handler I mentioned in my answer, which happens unpredictably because it is only raised when the garbage collector happens to notice that the task has no references to it, and when the garbage collector detects that depends on too many variables. `async void` leads to deterministic exception handling, as the exception will immediately be posted to the synchronisation context. –  Dec 17 '16 at 15:53
  • @hvd : I know its quite old post. Probably can you help me understand one thing - why its always said "avoid async void". I don't know, but i feel guideline should rather say - "await task". Because problem with async void is that caller will not know to await for completion and control will continue with execution of following statements. I can understand ill effect of this. But even if async method returns task instead of void, caller can miss to await and get into same issues. hence the question - why not guideline says - _always await task_ ? – rahulaga-msft Mar 15 '18 at 17:16
  • @RahulAgarwal It's not the caller won't know to use `await`, it's that the caller will definitely not be able to use `await` even if the caller *does* know. As for whether tasks should be `await`ed instead of discarded, yes, they should be, unless you use some other mechanism that achieves the same result (such as calling `.ContinueWith` explicitly). The only reason I'm not mentioning that in my answer is because it's not asked here and there wasn't any confusion over it. –  Mar 15 '18 at 18:14
  • Note: Calling 'f' will crash the whole process, regardless of the framework version, and raises the AppDomain.CurrentDomain.UnhandledException event if you run this in a console app. – Triynko Nov 24 '18 at 04:42
62

I have come across this very useful article about async and void written by Jérôme Laban: https://jaylee.org/archive/2012/07/08/c-sharp-async-tips-and-tricks-part-2-async-void.html

The bottom line is that an async+void can crash the system and usually should be used only on the UI side event handlers.

The reason behind this is the Synchronization Context used by the AsyncVoidMethodBuilder, being none in this example. When there is no ambient Synchronization Context, any exception that is unhandled by the body of an async void method is rethrown on the ThreadPool. While there is seemingly no other logical place where that kind of unhandled exception could be thrown, the unfortunate effect is that the process is being terminated, because unhandled exceptions on the ThreadPool effectively terminate the process since .NET 2.0. You may intercept all unhandled exception using the AppDomain.UnhandledException event, but there is no way to recover the process from this event.

When writing UI event handlers, async void methods are somehow painless because exceptions are treated the same way found in non-async methods; they are thrown on the Dispatcher. There is a possibility to recover from such exceptions, with is more than correct for most cases. Outside of UI event handlers however, async void methods are somehow dangerous to use and may not that easy to find.

Pang
  • 9,564
  • 146
  • 81
  • 122
Davide Icardi
  • 11,919
  • 8
  • 56
  • 77
  • Is that correct? I thought exceptions inside async methods are captured within Task. And also afaik there's always a deafault SynchronizationContext – N. M. Aug 30 '19 at 20:42
59

The problem with calling async void is that

you don’t even get the task back. You have no way of knowing when the function’s task has completed. —— Crash course in async and await | The Old New Thing

Here are the three ways to call an async function:

async Task<T> SomethingAsync() { ... return t; }
async Task SomethingAsync() { ... }
async void SomethingAsync() { ... }

In all the cases, the function is transformed into a chain of tasks. The difference is what the function returns.

In the first case, the function returns a task that eventually produces the t.

In the second case, the function returns a task which has no product, but you can still await on it to know when it has run to completion.

The third case is the nasty one. The third case is like the second case, except that you don't even get the task back. You have no way of knowing when the function's task has completed.

The async void case is a "fire and forget": You start the task chain, but you don't care about when it's finished. When the function returns, all you know is that everything up to the first await has executed. Everything after the first await will run at some unspecified point in the future that you have no access to.

Pang
  • 9,564
  • 146
  • 81
  • 122
user8128167
  • 6,929
  • 6
  • 66
  • 79
14

I think you can use async void for kicking off background operations as well, so long as you're careful to catch exceptions. Thoughts?

class Program {

    static bool isFinished = false;

    static void Main(string[] args) {

        // Kick off the background operation and don't care about when it completes
        BackgroundWork();

        Console.WriteLine("Press enter when you're ready to stop the background operation.");
        Console.ReadLine();
        isFinished = true;
    }

    // Using async void to kickoff a background operation that nobody wants to be notified about when it completes.
    static async void BackgroundWork() {
        // It's important to catch exceptions so we don't crash the appliation.
        try {
            // This operation will end after ten interations or when the app closes. Whichever happens first.
            for (var count = 1; count <= 10 && !isFinished; count++) {
                await Task.Delay(1000);
                Console.WriteLine($"{count} seconds of work elapsed.");
            }
            Console.WriteLine("Background operation came to an end.");
        } catch (Exception x) {
            Console.WriteLine("Caught exception:");
            Console.WriteLine(x.ToString());
        }
    }
}
bboyle1234
  • 4,859
  • 2
  • 24
  • 29
  • 4
    The problem with calling async void is that you don’t even get the task back, you have no way of knowing when the function’s task has completed – user8128167 Jun 19 '18 at 15:27
  • 2
    This does make sense for (rare) background operations where you don't care about the result and you don't want an exception to affect other operations. A typical use case would be sending a log event to a log server. You want this to happen in the background, and you don't want your service / request handler to fail if the log server is down. Of course, you have to catch all exceptions, or your process will be terminated. Or is there a better way to achieve this? – Florian Winter Aug 27 '18 at 08:57
  • 1
    Exceptions from an Async Void Method Can’t Be Caught with Catch. https://msdn.microsoft.com/en-us/magazine/jj991977.aspx – Si Zi Oct 16 '18 at 11:43
  • 6
    @SiZi the catch is INSIDE the async void method as shown in the example and it is caught. – bboyle1234 Oct 16 '18 at 21:34
  • 1
    What about when your requirements change to require doing no work if you cant log it - then you have to change the signatures in your whole API, instead of just changing the logic which currently has // Ignore Exception – Milney Jan 16 '20 at 18:44
  • 1
    @Milney - I'm a strong believer in "Incremental" design. Don't make a decision until the need is demonstrated. If requirements change such that the caller is responsible for exceptions, then that *is* an API change. As seen in code above, an `async void` method *is* responsible for catching its exceptions. OTOH, its easier and safer to make it `async Task` (where appropriate), [don't have to be aware that try..catch is essential], so I'm not arguing against that. I'm just saying that worrying about API changes is appropriate where its appropriate - but not where its not significant. – ToolmakerSteve Aug 20 '22 at 19:16
2

A brief explanation:
async Task<T> method() await can be used to wait till the execution is completed and it will return value of type T
async Task method() await can be used to wait till the execution is completed but no data is returned
async void method() can't be awaited and no data is returned [Example: async event execution]

Amit Bisht
  • 4,870
  • 14
  • 54
  • 83
-6

My answer is simple you can not await void method

Error   CS4008  Cannot await 'void' TestAsync   e:\test\TestAsync\TestAsyncProgram.cs

So if the method is async, it is better to be awaitable, because you can lose the advantage ofasync.

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
Serg Shevchenko
  • 662
  • 1
  • 5
  • 21
  • the void async method used for event handlers. So its necessary to use async where you don't want to wait for the completion. – shanavascet Jul 15 '22 at 16:30
  • @shanavascet then what is difference beetwen classic void method and void task? – zeroG Nov 08 '22 at 01:58