What's the difference between returning void and returning a Task?

Question

In looking at various C# Async CTP samples I see some async functions that return void, and others that return the non-generic Task. I can see why returning a Task<MyType> is useful to return data to the caller when the async operation completes, but the functions that I've seen that have a return type of Task never return any data. Why not return void?

Ole

Answer 1

SLaks and Killercam's answers are good; I thought I'd just add a bit more context.

Your first question is essentially about what methods can be marked async.

A method marked as async can return void, Task or Task<T>. What are the differences between them?

A Task<T> returning async method can be awaited, and when the task completes it will proffer up a T.

A Task returning async method can be awaited, and when the task completes, the continuation of the task is scheduled to run.

A void returning async method cannot be awaited; it is a "fire and forget" method. It does work asynchronously, and you have no way of telling when it is done. This is more than a little bit weird; as SLaks says, normally you would only do that when making an asynchronous event handler. The event fires, the handler executes; no one is going to "await" the task returned by the event handler because event handlers do not return tasks, and even if they did, what code would use the Task for something? It's usually not user code that transfers control to the handler in the first place.

Your second question, in a comment, is essentially about what can be awaited:

What kinds of methods can be awaited? Can a void-returning method be awaited?

No, a void-returning method cannot be awaited. The compiler translates await M() into a call to M().GetAwaiter(), where GetAwaiter might be an instance method or an extension method. The value awaited has to be one for which you can get an awaiter; clearly a void-returning method does not produce a value from which you can get an awaiter.

Task-returning methods can produce awaitable values. We anticipate that third parties will want to create their own implementations of Task-like objects that can be awaited, and you will be able to await them. However, you will not be allowed to declare async methods that return anything but void, Task or Task<T>.

(UPDATE: My last sentence there may be falsified by a future version of C#; there is a proposal to allow return types other than task types for async methods.)

(UPDATE: The feature mentioned above made it in to C# 7.)

Brookbrooke

+1 I think the only thing missing is the difference in how exceptions are treated in void-returning async methods. – Secessionist

Great explanation, thanks Eric! I am curious as to what João is referring to about differences in exceptions. – Ole

@JamesCadd: Suppose some asynchronous work throws an exception. Who catches it? The code that started the asynchronous task is not on the stack anymore -- it might not even be on the same thread -- and exceptions assume that all the catch/finally blocks are on the stack. So what do you do? We store the exception information in the Task, so that you can inspect it later. But if the method is void returning then there is no Task available to user code. How exactly we deal with that situation has been a matter of some controversy and I do not recall at this moment what we decided on. – Brookbrooke

I actually asked this question of Stephen Toub at BUILD. In .NET 4.0 unobserved, unhandled exceptions in Tasks would eventually crash the process once TPL detects they were not observed. In 4.5 they've changed the default behavior so that unobserved exceptions will still be reported via the TaskScheduler::UnobservedTaskException event, but will no longer crash the process. If you want the old 4.0 behavior you can opt back in with <runtime><ThrowUnobservedTaskExceptions enabled="true"/></runtime>. Most likely the change was made precisely for supporting fire-and-forget for void async methods. – Rancidity

async void methods raise their exception on the SynchronizationContext that was active at the time they started executing. This is similar to the behavior of (synchronous) event handlers. @DrewMarsh: the UnobservedTaskException and runtime setting only apply to "fire and forget" async Task methods, not async void methods. – Tarr

Citation link for async exception handling info: blogs.msdn.com/b/pfxteam/archive/2012/04/12/10293335.aspx#11 – Keenan

Answer 2

In case the caller wants to wait on the task or add a continuation.

In fact, the only reason to return void is if you cannot return Task because you're writing an event handler.

Thule

I thought it was possible to await methods that return a void type as well - could you elaborate a bit? – Ole

No, you can't. If the method returns void, you have no way of getting at the task that it generates. (Actually, I'm not sure whether it even generates a Task at all) – Thule

Answer 3

Methods returning Task and Task<T> are composable - meaning that you can await them inside of an async method.

async methods returning void are not composable, but they do have two other important properties:

1. They can be used as event handlers.
2. They represent a "top-level" asynchronous operation.

The second point is important when you're dealing with a context that maintains a count of outstanding asynchronous operations.

The ASP.NET context is one such context; if you use async Task methods without awaiting them from an async void method, then the ASP.NET request will be completed too early.

Another context is the AsyncContext I wrote for unit testing (available here) - the AsyncContext.Run method tracks the outstanding operation count and returns when it's zero.

Tarr

Answer 4

Type Task<T> is the workhorse type of the Task Parallel Library (TPL), it represents the concept of "some work/job that is going to produce a result of type T in the future". The concept of "work that will complete in the future but returns no result" is represented by the non-generic Task type.

Precisely how the result of type T is going to be produced is and implementation detail of a particular task; the work might be farmed out to another process on the local machine, to another thread etc. TPL tasks are typically farmed out to worker threads from a thread pool in the the current process, but that implementation detail is not fundamental to the Task<T> type; rather a Task<T> can represent any high-latency operation that produces a T.

Based on your comment above:

The await expression means "evaluate this expression to obtain an object representing work that will in future produce a result. Sign up the remainder of the current method as the call back associated with the continuation of that task. Once that task is produced and the call back is signed up, immediately return control to my caller". This is opposed/in contrast to a regular method call, which means "remember what you're doing, run this method until it is completely finished and then pick up where you left off, now knowing the result of the method".

---

Edit: I should cite Eric Lippert's article in October 2011 MSDN Magazine as this was a great help to me in understanding this stuff in the first place.

For loads more infromation and whitepages see here.

I hope this is of some help.

Psychology