Difference between await and ContinueWith

In the second code, you're synchronously waiting for the continuation to complete. In the first version, the method will return to the caller as soon as it hits the first await expression which isn't already completed.

They're very similar in that they both schedule a continuation, but as soon as the control flow gets even slightly complex, await leads to much simpler code. Additionally, as noted by Servy in comments, awaiting a task will "unwrap" aggregate exceptions which usually leads to simpler error handling. Also using await will implicitly schedule the continuation in the calling context (unless you use ConfigureAwait). It's nothing that can't be done "manually", but it's a lot easier doing it with await.

I suggest you try implementing a slightly larger sequence of operations with both await and Task.ContinueWith - it can be a real eye-opener.

• The error handling between the two snippets is also different; it's generally easier to work with await over ContinueWith in that regard. - Servy
• @Servy: True, will add something around that. - Jon Skeet
• The scheduling is also quite different, i.e., what context parseData executes in. - Stephen Cleary
• @StephenCleary: Agreed. Again, will edit. - Jon Skeet
• @Harrison: Imagine you're writing a WinForms app - if you write an async method, by default all of the code within the method will run in the UI thread, because the continuation will be scheduled there. If you don't specify where you want the continuation to run, I don't know what the default is but it could easily end up running on a thread pool thread... at which point you can't access the UI, etc. - Jon Skeet

Here's the sequence of code snippets I recently used to illustrate the difference and various problems using async solves.

Suppose you have some event handler in your GUI-based application that takes a lot of time, and so you'd like to make it asynchronous. Here's the synchronous logic you start with:

while (true) {
    string result = LoadNextItem().Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
        break;
    }
}

LoadNextItem returns a Task, that will eventually produce some result you'd like to inspect. If the current result is the one you're looking for, you update the value of some counter on the UI, and return from the method. Otherwise, you continue processing more items from LoadNextItem.

First idea for the asynchronous version: just use continuations! And let's ignore the looping part for the time being. I mean, what could possibly go wrong?

return LoadNextItem().ContinueWith(t => {
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
});

Great, now we have a method that does not block! It crashes instead. Any updates to UI controls should happen on the UI thread, so you will need to account for that. Thankfully, there's an option to specify how continuations should be scheduled, and there's a default one for just this:

return LoadNextItem().ContinueWith(t => {
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
},
TaskScheduler.FromCurrentSynchronizationContext());

Great, now we have a method that does not crash! It fails silently instead. Continuations are separate tasks themselves, with their status not tied to that of the antecedent task. So even if LoadNextItem faults, the caller will only see a task that has successfully completed. Okay, then just pass on the exception, if there is one:

return LoadNextItem().ContinueWith(t => {
    if (t.Exception != null) {
        throw t.Exception.InnerException;
    }
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
},
TaskScheduler.FromCurrentSynchronizationContext());

Great, now this actually works. For a single item. Now, how about that looping. Turns out, a solution equivalent to the logic of the original synchronous version will look something like this:

Task AsyncLoop() {
    return AsyncLoopTask().ContinueWith(t =>
        Counter.Value = t.Result,
        TaskScheduler.FromCurrentSynchronizationContext());
}
Task<int> AsyncLoopTask() {
    var tcs = new TaskCompletionSource<int>();
    DoIteration(tcs);
    return tcs.Task;
}
void DoIteration(TaskCompletionSource<int> tcs) {
    LoadNextItem().ContinueWith(t => {
        if (t.Exception != null) {
            tcs.TrySetException(t.Exception.InnerException);
        } else if (t.Result.Contains("target")) {
            tcs.TrySetResult(t.Result.Length);
        } else {
            DoIteration(tcs);
        }});
}

Or, instead of all of the above, you can use async to do the same thing:

async Task AsyncLoop() {
    while (true) {
        string result = await LoadNextItem();
        if (result.Contains("target")) {
            Counter.Value = result.Length;
            break;
        }
    }
}

That's a lot nicer now, isn't it?

• Thanks, really nice explanation - Elger Mensonides
• This is a great example - Royi Namir
• this still doenst update the UI. pastebin.com/Y8NddKp5 - MonsterMMORPG
• Thanks @pkt for the excellent explanation \o/ - Uilque Messias