Какова цель «возврата ждать» в C #?

Есть ли какой - либо сценарий , где метод записи , как это:

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

вместо этого:

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

будет иметь смысл?

Зачем использовать return awaitконструкцию, если вы можете напрямую вернуться Task<T>из внутреннего DoAnotherThingAsync()вызова?

Я вижу код return awaitво многих местах, думаю, я мог что-то пропустить. Но, насколько я понимаю, отсутствие использования ключевых слов async / await в этом случае и прямой возврат Задачи будет функционально эквивалентным. Зачем добавлять дополнительные накладные расходы на дополнительный awaitслой?

Есть один хитрый случай, когда returnв обычном методе и return awaitв asyncметоде ведут себя по-разному: в сочетании с using(или, в более общем случае, любым return awaitв tryблоке).

Рассмотрим эти две версии метода:

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Первый метод будет объект как только возвращает метод, который, вероятно , задолго до того , как на самом деле завершается. Это означает, что первая версия, вероятно, глючит (потому что удаляется слишком рано), тогда как вторая версия будет работать нормально.Dispose()FooDoAnotherThingAsync()Foo

Если вам не нужно async(то есть вы можете вернуть Taskнапрямую), то не используйте async.

В некоторых ситуациях return awaitэто полезно, например, если вам нужно выполнить две асинхронные операции:

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

Подробнее о asyncпроизводительности читайте в статье Стивена Тауба и видео MSDN на эту тему.

Обновление: я написал сообщение в блоге, которое входит в гораздо более подробную информацию.

Единственная причина, по которой вы захотите это сделать, - это то, что awaitв более раннем коде есть какие-то другие , или если вы каким-то образом манипулируете результатом перед его возвратом. Другим способом, которым это может происходить, является try/catchизменение, которое обрабатывает исключения. Если вы ничего не делаете, тогда вы правы, нет никаких причин добавлять накладные расходы на создание метода async.

Еще один случай, вам может потребоваться дождаться результата:

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

В этом случае GetIFooAsync()необходимо дождаться результата, GetFooAsyncтак как тип Tотличается между двумя методами и Task<Foo>не может быть напрямую назначен Task<IFoo>. Но если вы ждете результата, он просто становится , Fooкоторый находится непосредственно присваиваемый IFoo. Затем асинхронный метод просто переупаковывает результат внутри, Task<IFoo>и все готово.

Создание в противном случае простого метода «thunk» async создает в памяти асинхронный конечный автомат, а не асинхронный - нет. Хотя это часто может указывать людям на использование неасинхронной версии, поскольку она более эффективна (что верно), это также означает, что в случае зависания у вас нет никаких доказательств того, что этот метод задействован в «стеке возврата / продолжения» что иногда затрудняет понимание зависания.

Так что да, когда perf не критичен (и обычно это не так), я включу асинхронность во всех этих методах thunk, чтобы у меня был асинхронный конечный автомат, чтобы помочь мне диагностировать зависания позже, а также чтобы гарантировать, что если эти Методы thunk постоянно развиваются, и они будут возвращать ошибочные задачи вместо броска.

Если вы не используете return await, вы можете испортить трассировку стека во время отладки или когда она печатается в журналах исключений.

Когда вы возвращаете задачу, метод выполнил свою задачу, и он вышел из стека вызовов. Когда вы используетеreturn await вы оставляете его в стеке вызовов.

Например:

Стек вызовов при использовании await: A ожидает задачи от B => B ожидает задачи от C

Стек вызовов, когда не используется await: A ожидает задачу от C, которую B вернул.

Это также смущает меня, и я чувствую, что предыдущие ответы упустили из виду ваш актуальный вопрос:

Зачем использовать конструкцию return await, если вы можете напрямую вернуть Task из внутреннего вызова DoAnotherThingAsync ()?

Ну, иногда вы действительно хотите Task<SomeType>, но в большинстве случаев вам нужен экземплярSomeType , то есть результат задачи.

Из вашего кода:

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Человек, незнакомый с синтаксисом (например, я), может подумать, что этот метод должен возвращать a Task<SomeResult>, но, поскольку он помечен async, это означает, что его фактический тип возврата равен SomeResult. Если вы просто используете return foo.DoAnotherThingAsync(), вы будете возвращать задачу, которая не будет компилироваться. Правильный способ - вернуть результат задачи, поэтому return await.