Cancel async functions without throw

[timcassell]

I originally posted an idea at dotnet/runtime#48482 but realized that wouldn't work because I didn't account for awaiting things within finally blocks.

To summarize: Exceptions are slow and should not be used to control program flow. The aging async Task API was architected to cancel via throw new OperationCanceledException(). How can we modernize async functions to stop going against normal code best practices and improve performance at the same time?

Note: I don't have any experience with async iterators, so this is for regular async methods.

I was hoping to be able to do this without adding any new keywords, but I think that will be necessary for this purpose. Currently the 2 keywords to control async flow are throw and await. I propose adding cancelthrow and cancelawait context-sensitive keywords. In order to preserve backwards compatibility, these keywords are only valid if the async return type's AsyncMethodBuilder implement new optional methods (more on that further down).

Consider this async method that is valid today:

public async Task<int> Func(CancellationToken token)
{
    await Task.Delay(10);
    token.ThrowIfCancellationRequested(); // Cancel the task if the token is canceled.
    return 100;
}

We could adjust that to work without throwing like this:

public async Task<int> Func(CancellationToken token)
{
    await Task.Delay(10);
    if (token.IsCancellationRequested)
    {
        cancelthrow; // Cancel the task if the token is canceled.
    }
    return 100;
}

That's a little more verbose, but it would be able to cancel the task much more efficiently. We could write an extension method to do that inline:

public async Task<int> Func(CancellationToken token)
{
    await Task.Delay(10);
    cancelawait token.GetCancelAwaitable(); // Cancel the task if the token is canceled.
    return 100;
}

And that extension looks like this:

public static class CancellationTokenExtensions
{
    public struct CancellationTokenCancelAwaitable : INotifyCompletion, IAsyncCanceler
    {
        private readonly CancellationToken _token;

        public CancellationTokenCancelAwaitable(CancellationToken token)
        {
            _token = token;
        }

        public CancellationTokenCancelAwaitable GetAwaiter() => this;
        public bool IsCompleted => true; // Never wait
        public bool IsCanceled => _token.IsCancellationRequested; // Is the token canceled?
        public void GetResult() { } // Do nothing if the token is not canceled.
        public void OnCompleted(Action continuation) => throw new NotImplementedException(); // Don't need to implement since we never wait.
    }

    public static CancellationTokenCancelAwaitable GetCancelAwaitable(this CancellationToken token)
    {
        return new CancellationTokenCancelAwaitable(token);
    }
}

Notice how it utilizes the already existing duck-typing to create an awaitable type. This just took it a step further and added the IAsyncCanceler interface to support the cancelawait keyword:

public interface IAsyncCanceler
{
    bool IsCanceled { get; }
}

cancelawait is can only be used on an instance that is both awaitable and implements IAsyncCanceler. The example I gave above didn't actually utilize the "awaitable" part, it just synchronously checks if the token is canceled or not. With the normal await keyword, the compiler generates code conceptually similar to this pseudo-code (not counting exceptions and AsyncMethodBuilder intricacies here):

if (awaiter.IsCompleted)
{
    GetResult();
}
else
{
    awaiter.OnCompleted(GetResult);
}

void GetResult()
{
    awaiter.GetResult();
    ContinueExecution();
}

cancelawait would generate slightly more expanded code:

if (awaiter.IsCompleted)
{
    GetResultOrCancel();
}
else
{
    awaiter.OnCompleted(GetResultOrCancel);
}

void GetResultOrCancel()
{
    if (awaiter.IsCanceled)
    {
        CancelTask();
    }
    else
    {
        awaiter.GetResult();
        ContinueExecution();
    }
}

So we could utilize the "awaitable" part to perform a more complex operation, such an waiting for another task to complete then canceling the current task without executing any more code after the cancelawait keyword.

public async Task<int> Func(CancellationToken token)
{
    cancelawait WaitThenCancel().GetCancelAwaitable(); // Wait for the task to complete, then cancel this task if it's canceled.
    return 100;

    async Task WaitThenCancel()
    {
        await Task.Delay(10);
        cancelthrow; // Cancel the task.
    }
}

I'll leave out the rest of the extension for that, but the IsCompleted, IsCanceled, and OnCompleted might look something like this:

public bool IsCompleted => _task.Status == TaskStatus.RanToCompletion | _task.Status == TaskStatus.Canceled | _task.Status == TaskStatus.Faulted;
public bool IsCanceled => _task.Status == TaskStatus.Canceled;
public void OnCompleted(Action continuation) => _task.ContinueWith(_ => continuation());

The cancelation would be propagated to the task the same way throw new OperationCanceledException would, but without the actual throw. This means that any try/finally blocks would behave the same way (finally always executes, await inside finally works). If an exception is thrown inside a finally block, it "overwrites" the cancelation, just like it would any other exception.

public async Task<int> Func(CancellationToken token)
{
    try
    {
        await Task.Delay(10);
        cancelthrow; // Cancel the task.
        return 100; // Unreachable code.
    }
    finally
    {
        await Task.Delay(10); // Delay the cancelation.
        throw new Exception(); // Actually, we're going to fault the task instead of cancel.
    }
}

Now, what do the new AsyncMethodBuilders look like? Here is an example of a simple method builder for a task-like Promise type (AsyncPromiseRef implementation removed for brevity):

public struct PromiseMethodBuilder<T>
{
    private AsyncPromiseRef _promise;

    public Promise<T> Task
    {
        get { return new Promise<T>(_promise, _promise.Id); }
    }

    public static PromiseMethodBuilder<T> Create()
    {
        return new PromiseMethodBuilder<T>()
        {
            _promise = AsyncPromiseRef.GetOrCreate()
        };
    }

    public void SetException(Exception exception)
    {
        if (exception is OperationCanceledException)
        {
            _promise.SetCanceled(exception);
        }
        else
        {
            _promise.SetException(exception);
        }
    }

    public void SetResult(T result)
    {
        _promise.SetResult(result);
    }

    public void AwaitOnCompleted<TAwaiter, TStateMachine>(ref TAwaiter awaiter, ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine
    {
        awaiter.OnCompleted(_promise.GetContinuation(ref stateMachine));
    }

    [SecuritySafeCritical]
    public void AwaitUnsafeOnCompleted<TAwaiter, TStateMachine>(ref TAwaiter awaiter, ref TStateMachine stateMachine)
        where TAwaiter : ICriticalNotifyCompletion
        where TStateMachine : IAsyncStateMachine
    {
        awaiter.UnsafeOnCompleted(_promise.GetContinuation(ref stateMachine));
    }

    public void Start<TStateMachine>(ref TStateMachine stateMachine)
        where TStateMachine : IAsyncStateMachine
    {
        stateMachine.MoveNext();
    }

    public void SetStateMachine(IAsyncStateMachine stateMachine) { }
}

SetResult and SetException are called after the entire async function has no more code to execute so that the returned Promise<T> can have its state applied and any callbacks applied to it called. All we have to do now is add a new end-of-function method for cancelations:

public void SetCancelation()
{
    _promise.SetCanceled();
}

For backwards compatibility, this method is optional, and as mentioned above, the cancelthrow and cancelawait are only valid as keywords if that method exists in the method builder.

And that's it... but wait! What if you want your custom task-like type to handle custom cancelations? With the current throw exception method of canceling, you can simply create a new exception that inherits from OperationCanceledException and do whatever you want! How could we support that with this new paradigm? That's easy, just add another optional SetCancelation method to the builder:

public void SetCancelation<TCanceler>(TCanceler canceler)
{
    SetCancelation();
}

How this works is, when an IAsyncCanceler instance returns true from IsCanceled, if this generic method exists, that instance is passed to the generic method. Otherwise, the non-generic void method is called. Only one of these methods will be called by the statemachine (one is free to call the other directly of course). Also, notice that there are no generic constraints, you can cancel it with anything! The way that works is you put whatever you want to cancel the task with after the cancelthrow keyword.

public async Promise<int> Func(CancellationToken token)
{
    await Task.Delay(10);
    if (token.IsCancellationRequested)
    {
        cancelthrow -1; // Cancel the promise with `-1` as the reason if the token is canceled.
    }
    return 100;
}

This cancelthrow x; syntax is only valid if the generic method exists in the method builder.

This particular syntax should be easy for the compiler to handle in most cases, but it can get more complicated if there are any cancelthrows or cancelawaits within nested finally blocks, because the types can be anything, and whatever cancelation is "thrown" last should overwrite the previous. But as an implementation detail, it should still be manageable with integers mapped to their cancelation variables and using a switch to determine what was the last cancelation after all finally blocks complete.

[CyrusNajmabadi]

It's not really clear to me that problem this is solving.

[timcassell]

Exceptions are slow and should not be used to control program flow, yet that's exactly how async functions are designed to work. This is really more of a performance feature (because it still has the "throw" semantics).

[CyrusNajmabadi]

Can you provide some data to back this up? Also, if this really is a substantive improvement, it would be far better if we could just respec the language to allow for this by default so all existing programs speedup, instead of needing a new form that would only benefit 0.001% of all new code written to use it IMO.

[theunrepentantgeek]

Exceptions are slow and should not be used to control program flow,

This seems overly simplistic.

While it's true that exceptions are slower than other approaches to flow control, they're not actually that slow.

It's also worth noting that non-local flow control is exactly what exceptions are for, making them the right solution for the rare case where async tasks need to be interrupted.

[bernd5]

Is it really required to change the language for that? In my eyes the exception could be optimized away and replaced by a compiler in such a way that the lowered code behaves equally (just faster).
It could simply return a canceled Task / ValueTask created via "FromCanceled".

[YairHalberstadt]

I think there is actually room for the compiler to optimize wihout doing language changes:

Consider the following super simple async function:

using System;
using System.Threading.Tasks;

public class C {
    public async Task<int> M(bool b) {
        await Task.Yield();
        if (b)
            throw new Exception();
        return 42;
    }
}

This translates into a state machine that looks like this:

using System;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;

public class C
{
    private struct Md__0 : IAsyncStateMachine
    {
        public int _1__state;

        public AsyncTaskMethodBuilder<int> t__builder;

        public bool b;

        private YieldAwaitable.YieldAwaiter u__1;

        public void MoveNext()
        {
            int num = _1__state;
            int result;
            try
            {
                YieldAwaitable.YieldAwaiter awaiter;
                if (num != 0)
                {
                    awaiter = Task.Yield().GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        num = (_1__state = 0);
                        u__1 = awaiter;
                        t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                        return;
                    }
                }
                else
                {
                    awaiter = u__1;
                    u__1 = default(YieldAwaitable.YieldAwaiter);
                    num = (_1__state = -1);
                }
                awaiter.GetResult();
                if (b)
                {
                    throw new Exception();
                }
                result = 42;
            }
            catch (Exception exception)
            {
                _1__state = -2;
                t__builder.SetException(exception);
                return;
            }
            _1__state = -2;
            t__builder.SetResult(result);
        }

        public void SetStateMachine(IAsyncStateMachine stateMachine)
        {
            t__builder.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(Md__0))]
    public Task<int> M(bool b)
    {
        Md__0 stateMachine = default(Md__0);
        stateMachine.t__builder = AsyncTaskMethodBuilder<int>.Create();
        stateMachine.b = b;
        stateMachine._1__state = -1;
        stateMachine.t__builder.Start(ref stateMachine);
        return stateMachine.t__builder.Task;
    }
}

We throw an exception, and then immediately catch it, move to a new state of the statemachine, and return.

The compiler could spot that this will always happen, and instead generate the following equivalent code:

using System;
using System.Runtime.CompilerServices;
using System.Runtime.ExceptionServices;
using System.Threading.Tasks;

public class C
{
    private struct Md__0 : IAsyncStateMachine
    {
        public int _1__state;

        public AsyncTaskMethodBuilder<int> t__builder;

        public bool b;

        private YieldAwaitable.YieldAwaiter u__1;

        public void MoveNext()
        {
            int num = _1__state;
            int result;
            try
            {
                YieldAwaitable.YieldAwaiter awaiter;
                if (num != 0)
                {
                    awaiter = Task.Yield().GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        num = (_1__state = 0);
                        u__1 = awaiter;
                        t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                        return;
                    }
                }
                else
                {
                    awaiter = u__1;
                    u__1 = default(YieldAwaitable.YieldAwaiter);
                    num = (_1__state = -1);
                }
                awaiter.GetResult();
                if (b)
                {
                   _1__state = -2;
                   t__builder.SetException(ExceptionDispatchInfo.SetCurrentStackTrace(new Exception()));
                   return;
                }
                result = 42;
            }
            catch (Exception exception)
            {
                _1__state = -2;
                t__builder.SetException(exception);
                return;
            }
            _1__state = -2;
            t__builder.SetResult(result);
        }

        public void SetStateMachine(IAsyncStateMachine stateMachine)
        {
            t__builder.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(Md__0))]
    public Task<int> M(bool b)
    {
        Md__0 stateMachine = default(Md__0);
        stateMachine.t__builder = AsyncTaskMethodBuilder<int>.Create();
        stateMachine.b = b;
        stateMachine._1__state = -1;
        stateMachine.t__builder.Start(ref stateMachine);
        return stateMachine.t__builder.Task;
    }
}

We could do even better if awaitables has a custom Exception property, where they would store the Exception that would be thrown if GetResult were called. Then this could be further optimized to:

using System;
using System.Runtime.CompilerServices;
using System.Runtime.ExceptionServices;
using System.Threading.Tasks;

public class C
{
    private struct Md__0 : IAsyncStateMachine
    {
        public int _1__state;

        public AsyncTaskMethodBuilder<int> t__builder;

        public bool b;

        private YieldAwaitable.YieldAwaiter u__1;

        public void MoveNext()
        {
            int num = _1__state;
            int result;
            try
            {
                YieldAwaitable.YieldAwaiter awaiter;
                if (num != 0)
                {
                    awaiter = Task.Yield().GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        num = (_1__state = 0);
                        u__1 = awaiter;
                        t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                        return;
                    }
                }
                else
                {
                    awaiter = u__1;
                    u__1 = default(YieldAwaitable.YieldAwaiter);
                    num = (_1__state = -1);
                }
                if (awaiter.Exception is {} exception)
                {
                   _1__state = -2;
                   t__builder.SetException(exception);
                   return;
                }
                awaiter.GetResult();
                if (b)
                {
                   _1__state = -2;
                   t__builder.SetException(ExceptionDispatchInfo.SetCurrentStackTrace(new Exception()));
                   return;
                }
                result = 42;
            }
            catch (Exception exception)
            {
                _1__state = -2;
                t__builder.SetException(exception);
                return;
            }
            _1__state = -2;
            t__builder.SetResult(result);
        }

        public void SetStateMachine(IAsyncStateMachine stateMachine)
        {
            t__builder.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(Md__0))]
    public Task<int> M(bool b)
    {
        Md__0 stateMachine = default(Md__0);
        stateMachine.t__builder = AsyncTaskMethodBuilder<int>.Create();
        stateMachine.b = b;
        stateMachine._1__state = -1;
        stateMachine.t__builder.Start(ref stateMachine);
        return stateMachine.t__builder.Task;
    }
}

This would avoid rethrowing and recatching an exception at every level of an async stack trace every time it's awaited.

However I don't believe any language changes are needed here, only compiler changes, plus libraries would have to start adding the Exception property.

[yaakov-h]

The debugger would need to be able to break on the SetException calls then, and I’m not sure that the StackTrace would be set correctly. I suspect these are some of the reasons behind why it is currently thrown and then immediately caught.

[timcassell]

I'm not sure why you would want to break on cancelations, but the state machine behavior could be altered in DEBUG mode just like how it currently makes the state machine a class instead of struct in DEBUG.

Also, @YairHalberstadt demonstrated how the new ExceptionDispatchInfo.SetCurrentStackTrace api can be used to set the stacktrace properly. I'm not sure how the speed of that call compares to throw, but it wouldn't be necessary to reset the stacktrace on every catch and rethrow up the async call chain for cancelations anyway (the way it currently does).

[AartBluestoke]

i don't think the language specifies that it should be caught and re-thrown at each step anyway? are people relying on that behaviour relying on undefined behaviour?

[timcassell]

Yeah, that's not a language specification, but it might be a Task specification. In any case, it should be up to the awaitable whether or not it actually throws imo.

[sharwell]

The compiler could spot that this will always happen, and instead generate the following equivalent code:

This loses the ability to handle first chance exceptions, both in the debugger and at runtime.

We could do even better if awaitables has a custom Exception property, where they would store the Exception that would be thrown if GetResult were called. Then this could be further optimized to:

This loses asynchronous stack information tracked as part of the exception.

[sharwell]

I agree that this is an obvious source of pain that needs to be resolved by the language and/or runtime. Failure to handle the cancellation case efficiently is the single most prevalent pain point in attempting to debug our own project (Roslyn.sln), to the point that I really haven't even tried to debug real instances in months (maybe years).

Under the current language limitations, I handle the cancellation case by using PerfView to identify the primary locations where exceptionally large numbers of exceptions get thrown. Often these are cases where a single high-level work item branches out to many smaller work items. Relocating the cancellation exception from all the small work items to the shared high-level work item reduces the number of cases where exceptions are thrown. An example can be seen in dotnet/roslyn#19652.

Two changes are needed to resolve this properly:

1. We need a way to await a task without throwing on cancellation. This will be resolved as part of Developers can have access to more options when configuring async awaitables runtime#47525, but could be implemented separately if you need the feature today.
2. async methods need a way to transition the state machine into the cancelled state without throwing an exception. This requires a language change. The one case I thought might work (an extension method public void AsyncTaskMethodBuilder.SetResult(CancellationToken cancellationToken) which would allow code to just return cancellationToken; on cancellation does not.

Without a proposal to fix the second item, the most straightforward resolution is to disallow the use of async on cancellation hot paths, similar to how we disallow the use of LINQ or iterator methods on allocation hot paths.

[CyrusNajmabadi]

Could you expand on:

Failure to handle the cancellation case efficiently is the single most prevalent pain point in attempting to debug our own project (Roslyn.sln),

I don't recall a single time cancellation has ever affected my debugging of roslyn, and I likely debug it multiple times a day.

[sharwell]

Not much to expand. Debugging is extremely slow as many minutes pass waiting for the diagnostic tools to log all the thousands of cancellation exceptions.

[timcassell]

1. We need a way to await a task without throwing on cancellation. This will be resolved as part of dotnet/runtime#47525, but could be implemented separately if you need the feature today.

Indeed, it can already done today (and is done by UniTask) which is why I didn't mention it in the OP.

2. async methods need a way to transition the state machine into the cancelled state without throwing an exception. This requires a language change. The one case I thought might work (an extension method public void AsyncTaskMethodBuilder.SetResult(CancellationToken cancellationToken) which would allow code to just return cancellationToken; on cancellation does not.

Without a proposal to fix the second item, the most straightforward resolution is to disallow the use of async on cancellation hot paths, similar to how we disallow the use of LINQ or iterator methods on allocation hot paths.

I think @YairHalberstadt found the solution to that without a language change.

[sharwell]

@timcassell The proposal from @YairHalberstadt is a good start for looking at this, but in its current form is not a viable solution to the problem presented. Problem (2) mentioned here remains the open question for resolving this issue.

[CyrusNajmabadi]

I would not be opposed to a couple of targeted changes to the compiler/API/runtime (not language). Specifically:

1. if not already being done, it woudl make sense to me that awaiting a task would fast-path if the task was canceled (similar to how we fast-path if the task is completed). If the task is canceled, we should just transition the containing state machine to the same canceled state, and leave the method. This would make it so that you only pay for the first cancellation exception, and then any higher awaits are just trivial non-exception-based transitions.
2. the compiler/api/runtime could potentially detect and recompile how ct.ThrowIfCancellationRequested() is called. In this case, this would be converted as allowing the async machine to handle this op, and determine what it wants to do (for example, not actually throwing an exception, but just transitioning the state machine. This sort of detected behavior could be potentially opted into by a new shape for the async machinery.

This would allow async/await to remain simple to code against and consistent with how it's been done the last 9 years, while getting any potential improvements here (if there are any) to avoid actually throwing.

[timcassell]

every fiber of my being would say: this is waiting for the CT to be triggered.

Good point. Perhaps a more descriptive method like await token.CancelAsyncIfCancelled() or something like that?

[jnm2]

Also, while unlikely

...oops 😳

[AartBluestoke]

Always fast-pathing

It wouldn't 'always' be fast-pathed. Only when it was safe to do so. i.e. naked cancellationToken.Throw... in a non try/catch scenario.

and it's also not possible to fast-track existing custom awaitables

Yes. This would require some new shape to opt into this mechanism.

If anything, CancellationToken should just be turned into an awaitable

That's an interesting idea. Though i think it woudl read very weird. if i have:

await cancellationToken;

would suggest a new member with a custom awaitable:
await cancellationToken.ThrowIfCancelled(); (or AbortIfCancelled, or something) could be added.

[HaloFour]

@jnm2

I was thinking that I probably wrote one at some point too. For a while I was obsessed with awaiting things.

[CyrusNajmabadi]

Good point. Perhaps a more descriptive method like await token.CancelAsyncIfCancelled() or something like that?

Yes. I would find that a lot more palatable :-)

[timcassell]

What if we combine @YairHalberstadt and @CyrusNajmabadi 's ideas?

Given this C# code

public class C
{
    public async Task<int> M()
    {
        try
        {
            await Task.Yield();
        }
        catch (InvalidOperationException)
        {
            Console.WriteLine("Invalid");   
        }
        catch (ArgumentException e)
        {
            Console.WriteLine(e.ToString());
        }
        return 42;
    }
}

Produces this equivalent state machine

public class C
{
    private struct Md__0 : IAsyncStateMachine
    {
        public int _1__state;

        public AsyncTaskMethodBuilder<int> t__builder;

        private YieldAwaitable.YieldAwaiter u__1;

        public void MoveNext()
        {
            int num = _1__state;
            int result;
            try
            {
                try
                {
                    YieldAwaitable.YieldAwaiter awaiter;
                    if (num != 0)
                    {
                        awaiter = Task.Yield().GetAwaiter();
                        if (!awaiter.IsCompleted)
                        {
                            num = (_1__state = 0);
                            u__1 = awaiter;
                            t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                            return;
                        }
                    }
                    else
                    {
                        awaiter = u__1;
                        u__1 = default(YieldAwaitable.YieldAwaiter);
                        num = (_1__state = -1);
                    }
                    awaiter.GetResult();
                }
                catch (InvalidOperationException)
                {
                    Console.WriteLine("Invalid");
                }
                catch (ArgumentException ex2)
                {
                    Console.WriteLine(ex2.ToString());
                }
                result = 42;
            }
            catch (Exception exception)
            {
                _1__state = -2;
                t__builder.SetException(exception);
                return;
            }
            _1__state = -2;
            t__builder.SetResult(result);
        }

        public void SetStateMachine(IAsyncStateMachine stateMachine)
        {
            t__builder.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(Md__0))]
    public Task<int> M()
    {
        Md__0 stateMachine = default(Md__0);
        stateMachine.t__builder = AsyncTaskMethodBuilder<int>.Create();
        stateMachine._1__state = -1;
        stateMachine.t__builder.Start(ref stateMachine);
        return stateMachine.t__builder.Task;
    }
}

We can rejigger it to this

public class C
{
    private struct Md__0 : IAsyncStateMachine
    {
        public int _1__state;

        public AsyncTaskMethodBuilder<int> t__builder;

        private YieldAwaitable.YieldAwaiter u__1;

        public void MoveNext()
        {
            int num = _1__state;
            int result;
            try
            {
                Exception ex = null;
                try
                {
                    YieldAwaitable.YieldAwaiter awaiter;
                    if (num != 0)
                    {
                        awaiter = Task.Yield().GetAwaiter();
                        if (!awaiter.IsCompleted)
                        {
                            num = (_1__state = 0);
                            u__1 = awaiter;
                            t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                            return;
                        }
                    }
                    else
                    {
                        awaiter = u__1;
                        u__1 = default(YieldAwaitable.YieldAwaiter);
                        num = (_1__state = -1);
                    }
                    ex = awaiter.Exception;
                    if (ex == null)
                    {
                        awaiter.GetResult();
                    }
                }
                catch (Exception e)
                {
                    ex = e;
                }
                if (ex != null)
                {
                    if (ex is InvalidOperationException)
                    {
                        Console.WriteLine("Invalid");
                    }
                    else if (ex is ArgumentException ex2)
                    {
                        Console.WriteLine(ex2.ToString());
                    }
                    else
                    {
                        _1__state = -2;
                        t__builder.SetException(ex);
                        return;
                    }
                }
                result = 42;
            }
            catch (Exception exception)
            {
                _1__state = -2;
                t__builder.SetException(exception);
                return;
            }
            _1__state = -2;
            t__builder.SetResult(result);
        }

        public void SetStateMachine(IAsyncStateMachine stateMachine)
        {
            t__builder.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(Md__0))]
    public Task<int> M()
    {
        Md__0 stateMachine = default(Md__0);
        stateMachine.t__builder = AsyncTaskMethodBuilder<int>.Create();
        stateMachine._1__state = -1;
        stateMachine.t__builder.Start(ref stateMachine);
        return stateMachine.t__builder.Task;
    }
}

As per @CyrusNajmabadi 's idea, the compiler would check for try/catch blocks and transform them into if (ex is Exception exception) checks instead. If there are no catches, it would just immediately exit via the fast path as per @YairHalberstadt 's example. This puts more work on the compiler, but it makes all existing code faster simply by awaitables implementing the Exception property, and it doesn't change how programmers interact with catching cancelations. Also, the compiler would only need to do this extra work if the awaitable implements the Exception property (though it may choose to do it either way).

[sharwell]

as they are still exceptions

Cancellation of an asynchronous operation does not require an exception be created (tasks can transition to the cancelled state using the CancellationToken alone). For me, the primary goal of resolving this issue is to remove the requirement that the exception be created when the async keyword is used. Without an exception instance, there is no object on which to place a stack trace.

[timcassell]

In that case, I think the awaiters will need an IsCanceled property and the async method builders need to add a SetCancelation() method. We wouldn't need any new keywords. To support custom cancelation objects, the awaiter can be passed to SetCancelation<TAwaiter>(ref TAwaiter canceledAwaiter) (Tasks would just ignore the awaiter, and custom builders can check the awaiter's type).

I guess then the only way to catch cancelations would be to make custom configured awaitables.

Would you have this done directly on Tasks so awaiting them always takes the fast path? Or would they remain the same and you have to configure the await to take the fast path (so that existing try/catch still works)?

[sharwell]

In that case, I think the awaiters will need an IsCanceled property

No need to change the awaiters. Code needing to avoid exceptions is generally rare. Statistical analysis of runtime exceptions tends to reveal single-digit numbers of "hot" locations where large numbers of exceptions are thrown today. These locations can switch to the new configured no-throw awaitables from dotnet/runtime#47525, and handle cancellation manually. Everything else is fine to stay working the way it already is.

[timcassell]

Yeah, I don't mean all awaiters, I just mean new awaiters that are built for this fast path.

[timcassell]

So is this good enough to start a proposal?

[timcassell]

#4565