Is prevTask.Wait() recommended to be used with ContinueWith (from the Tasks library)?

Question

So I was told recently that how I was using my .ContinueWith for Tasks was not the proper way to use them. I have yet to find evidence of this on the internet so I will ask

Answer 1

Ehhh.... I think some of the current answers are missing something: what happens with exceptions?

The only reason you would call Wait in a continuation would be to observe a potential exception from the antecedent in the continuation itself. The same observation would happen if you accessed Result in the case of a Task<T> and also if you manually accessed the Exception property. Frankly, I wouldn't call Wait or access Result because if there is an exception you'll pay the price of re-raising it which is unnecessary overhead. Instead you can just check the IsFaulted property off the antecedent Task. Alternatively you can create forked workflows by chaining on multiple sibling continuations that only fire based on either success or failure with TaskContinuationOptions.OnlyOnRanToCompletion and TaskContinuationOptions.OnlyOnFaulted.

Now, it's not necessary to observe the exception of the antecedent in the continuation, but you may not want your workflow to move forward if, say, "Step 1" failed. In that case: specifying TaskContinuationOptions.NotOnFaulted to your ContinueWith calls would prevent the continuation logic from ever even firing.

Keep in mind that, if your own continuations don't observe the exception, the person who is waiting on this overall workflow to complete is going to be the one to observe it. Either they're Waiting on the Task upstream or have tacked on their own continuation to know when it is complete. If it is the latter, their continuation would need to use the aforementioned observation logic.

Answer 2

You might also want to consider using Task.Run instead of Task.Factory.StartNew.

Stephen Cleary's blog post and the Stephen Toub's post that he references explain the differences. There is also a discussion in this answer.

Answer 3

From the MSDN on Task.Continuewith

The returned Task will not be scheduled for execution until the current task has completed. If the criteria specified through the continuationOptions parameter are not met, the continuation task will be canceled instead of scheduled.

I think that the way you expect it to work in the first example is the correct way.

Answer 4

You are using it correctly.

Creates a continuation that executes asynchronously when the target Task completes.

Source: Task.ContinueWith Method (Action as MSDN)

Having to call prevTask.Wait() in every Task.ContinueWith invocation seems like a weird way to repeat unnecessary logic - i.e. doing something to be "super duper sure" because you actually don't understand what a certain bit of code does. Like checking for a null just to throw an ArgumentNullException where it would've been thrown anyway.

So, no, whoever told you that is wrong and probably doesn't understand why Task.ContinueWith exists.

Answer 5

I will reiterate what many have spoken already, prevTask.Wait() is unnecessary.

For more examples one can go to Chaining Tasks using Continuation Tasks, yet another link by Microsoft with good examples.

Answer 6

By Accessing Task.Result you are actually doing similar logic to task.wait