Как правильно возвращать объект из async метода в .NET?

Question

[NameOf Var]

Всем привет! Есть вопрос по реализации async/await в .NET.

Приведу два примера:

1.

private Config _config;
private Config _defaultConfig => Config.GetDefaultConfig();

public async Task<Config> GetConfigAsync()
{
   if (_config == null)
   {
      return _defaultConfig; 
   }

   return await GetWebConfig("http://test.com");
}

Если выполнится условие в блоке if, то из метода GetConfigAsync будет возвращён объект типа Task.
Правильно ли оставлять в таком виде или лучше будет написать return await Task.FromResult(_defaultConfig)?

2.

public async Task<string> GetRequestResult()
{
   var response = await GetResponseFromUrl(url);

   if (response.isSuccess)
   {
      return "Success!";
   }
   else
   {
      return "Error!";
   }
}

В данном примере мне нужно просто проверить статус ответа от сервера. Если я помещу всё это в async Task, то при вызове метода GetRequestResult придётся писать await. Есть ли способ избежать этого? Нужно ли return оборачивать в Task.FromResult("Success")? Какие best-practice лучше применить? Уместен ли вариант с .Result в данном случае?

Answer 1

[eRKa]

1. У Вас корректные примеры, никаких await Task.FromResult не нужно.
2.

при вызове метода GetRequestResult придётся писать await

Придется. async/await заразен, он вынуждено подымается вверх по вызовам. С с .Result Вы убьете асинхронность, сомневаюсь, что в Ваше случае есть необходимость в его применении.

Бест практика одна - использовать его как будто это обычный метод, в этом и красота его применения. await перед вызовом говорит только, что вызывающий поток освободится. Ну и нужно помнить о контексте синхронизации и понимать когда можно сделать .ConfigureAwait(false).

Comments

[NameOf Var]

Тогда вот такой кейс. Имееются интерфейс, у этого интерфейса есть метод SendTextMessage, который возвращает Task

Предположим, что я не хочу реализовывать этот метод и хочу просто заглушить вот таким вот способом:

public async Task<string> SendTextMessage()
{
   return "Success";
}

В таком случае IDE подсвечивает мне надо бы приписать await где-нибудь. В данном случае стоит проигнорировать варнинги IDE?

[eRKa]

NameOf Var, можно игнорировать, он сам обернет это в задачу, можно конечно и return await Task.FromResult<string>("Success")

[Петр]

"await перед вызовом говорит только, что вызывающий поток освободится."
await такого не говорит.
Он означает, что оставшаяся часть кода метода продолжит работу в том же контексте, в котором метод был запущен и не более.

[eRKa]

Петр, не верно. Если выставить ConfigureAwait(false), то при продолжении поток в контекст заходить не будет, контекст будет потерян, но вызов при этом останется асинхронным. Этот параметр иногда выставляют для оптимизаций асинхронных вызовов в цикле, т.к. восстановление контекста операция затратная.

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

[Петр]

eRKa, Генерируемый IL код посмотрите, метод с await преобразуется в конечный автомат, то есть функция разбивается на части. И вот та часть, что после await будет выполнена дальше и в контексте изначального вызова функции. Я ничего не говорил о методе, что является параметром конструкции await. Для него можно и ConfigureAwait задать. Еще await не подразумевает многопоточность, он подразумевает многозадачность, и если явно не разрешить задаче выполняться в отдельном потоке (как вы указали ConfigureAwait(false)), то она и не будет. Пример есть тут

[eRKa]

Петр, Вы все правильно говорите, кроме того, что это указывает только на контекст. Вот Вам пример от сюда

// GET api/values
public async Task<IEnumerable<string>> Get()
{
    //Warning bad code

    //Context is present here. So you will get data.
    var httpContext = HttpContext.Current;
    httpContext.Request;
    httpContext.User;
    httpContext.Response;
    httpContext.AllErrors;
    httpContext.Session;
    
    await DoSomethingAsync().ConfigureAwait(false); //Will drop Context here.
    //Context is null here. 
    httpContext = HttpContext.Current;
    return new List<string>();
}

После await контекст будет потерян, он не будет восстанавливаться. И это касается не только asp.

Обратите внимание, что есть стандартное поведение

When the task resumes, it first enters the captured context before executing the remainder of the code.

Но это поведение можно отключить и контекст не будет восстанавливаться. Задача await не в том, чтобы указать на восстановление контекста, а в том, чтобы разделить на две части метод и пока выполняется ожидание длительного запроса, нужно вернуть управление потоком, дабы избежать блокировки основного потока. А уж будет потом восстановлен контекст или нет, это уже дело второе.