Not clear when the return task of an async function is set to a cancelled state

[pkulikov]

13.10.6 The throw statement section contains the following sentence:

If the current function is async and task-returning, the exception is recorded in the return task, which is put into a faulted or cancelled state as described in §15.15.2.

The linked 15.15.2 section contains only the following sentence relevant to the quoted sentence from 13.10.6:

If the function body terminates as the result of an uncaught exception (§13.10.6) the exception is recorded in the return task which is put into a faulted state.

When I read the sentence in 13.10.6, I expect that 15.15.2 explains the two things

• when the task is put into a faulted state and
• when the task is put into a cancelled state.

The current text of 15.15.2 doesn't explain that difference. Even more, it doesn't mention the cancelled state at all. So, one may think that the return task is always put into a faulted state, if an exception is thrown. That is not true, as the following example shows:

using System;
using System.Threading.Tasks;

public static class Program
{
    public static async Task Main(string[] args)
    {
        Task t = Async();
        try
        {
            await t;
        }
        catch
        {
            Console.WriteLine(t.IsFaulted);  // False
            Console.WriteLine(t.IsCanceled); // True
        }
    }

    public static async Task Async() => throw new OperationCanceledException();
}

So, 15.15.2 misses the description of when the return task is set to a cancelled state.

---

Associated WorkItem - 187389

[svick]

Isn't this a BCL concern and so shouldn't be described in detail by the C# specification in the first place?

[KalleOlaviNiemitalo]

Cancellation is also involved in IAsyncEnumerable<T> #606, in which EnumeratorCancellationAttribute needs compiler support and in my opinion should be standardised.

[SamB]

At the very least, the first quoted passage shouldn't say "is put into a faulted or cancelled state as described in [section that doesn't actually describe that]", right?

If the actual logic is in the BCL, then sure, it's fine if the referenced section merely refers in turn to the relevent BCL method documentation (whatever that might be), but if the logic gets open-coded then it should probably actually be described in the spec.

[KalleOlaviNiemitalo]

If an application defines and uses a task builder type whose builder.SetException(e) method does the same as builder.SetResult(default), i.e. does not record the exception, then does that violate the standard? How about if a C# implementation does that, in a task builder type that is not used for Task or Task<TResult>?

Perhaps 13.10.6 should say something like:

If the current function is async and task-returning, the exception is passed to the SetException method of the task builder as described in §15.15.2. [Note: In the task builder types associated with Task and Task<TResult>, SetException records the exception in the return task and puts it into a faulted or cancelled state.]