Яка мета "очікування повернення" в 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такою кількістю місць, я думаю, що, можливо, я щось пропустив. Але наскільки я розумію, не використовувати ключові слова асинхрон / очікувати в цьому випадку та безпосередньо повернути завдання було б функціонально рівнозначним. Навіщо додавати додаткові накладні витрати додаткового 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>та поза вами.

Здійснення інакше простого методу «обертання» async створює машину стану асинхронізації в пам’яті, тоді як не-асинхронний - ні. Хоча це часто може вказувати людям на використання не-асинхронної версії, оскільки вона є більш ефективною (що правда), це також означає, що у випадку зависання у вас немає доказів того, що цей метод бере участь у "стеці повернення / продовження" що іноді ускладнює розуміння повіси.

Тож так, коли перф не є критичним (а зазвичай це не так), я кину асинхронізу на всі ці способи громозвіння, щоб у мене з'явилася машина стану асинхронізації, яка допоможе мені діагностувати зависання пізніше, а також, щоб переконатися, що якщо ці Способи громіння колись розвиваються з часом, вони обов'язково повернуть несправні завдання замість кидка.

Якщо ви не будете використовувати return, чекайте, ви можете зруйнувати слід стека під час налагодження або коли він надрукується в журналах за винятками.

Після повернення завдання метод виконав своє призначення і він знаходиться поза стеком викликів. Коли ви використовуєтеreturn await ви залишаєте його в стеку дзвінків.

Наприклад:

Стек викликів при використанні в режимі await: Очікування завдання від B => B очікування завдання від C

Стек викликів, коли не використовується функція await: Очікування завдання від C, яке B повернуло.

Це також бентежить мене, і я відчуваю, що попередні відповіді не помітили вашого актуального питання:

Навіщо використовувати конструкцію return очікувати, коли ви можете безпосередньо повернути завдання із внутрішнього виклику DoAbodyThingAsync ()?

Ну, іноді ви дійсно хочете 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.