Oczekujcie lub Task.FromResult

Question

mam jedną usługę powiedzmy,

public interface ISomeService 
{ 
    Task<bool> DoSomeExpensiveCheckAsync(string parameter); 
} 

I mam tę klasę do konsumpcji usługi. Wystarczy wykonać kilka prostych sprawdzeń zerowych, a następnie zwrócić odpowiedź usługi.

public class SomeServiceConsumer 
{ 
    private readonly ISomeService _serviceClient; 

    public SomeServiceConsumer(ISomeService serviceClient) 
    { 
     _serviceClient = serviceClient; 
    } 

    public async Task<bool> DoSomething1Async(string someParameter) 
    { 
     if (string.IsNullOrWhiteSpace(someParameter)) 
     { 
      return false; 
     } 
     return await _serviceClient.DoSomeExpensiveCheckAsync(someParameter); 
    } 

    //No async or await keywords 
    public Task<bool> DoSomething2Async(string someParameter) 
    { 
     if (string.IsNullOrWhiteSpace(someParameter)) 
     { 
      return Task.FromResult(false); 
     } 
     return _serviceClient.DoSomeExpensiveCheckAsync(someParameter); 
    } 
} 

powinienem zrobić DoSomething1Async lub DoSomething2Async?

Według this answer, nie powinien zawijać z niepotrzebnym await ale potem muszę używać Task.FromResult(false) dla shortcircuiting jak w DoSomething2Async

Ale według this answer istnieją przypadki try/catch i using sprawozdania gdzie faktycznie powinien await przed powracający.

Czy mam rację mówiąc następnie, że

1. Jeśli muszę używać try/catch lub using potem powinno await

2. Inaczej nie await jeśli idziesz tylko do powrotu. I używać Task.FromResult do zwarcia

Lubię DoSomething1Async więcej, i chcę to zrobić wszędzie, jeśli ktoś mówi, że nie robi sprawy :).

Answer 1

Jeśli martwisz się o to, cache Task:

static readonly Task<bool> falseTask = Task.FromResult(false); 

async kluczowe otula również wyjątki w zwracana Task, wraz z odpowiednim ślad stosu. To kompromis, bezpieczeństwo zachowania dla perf.

Spójrzmy na scenariuszach różnicy, gdzie każdy będzie inaczej:

async Task UseSomething1Async(string someParameter) 
{ 
    // if IsNullOrWhiteSpace throws an exception, it will be wrapped in 
    // the task and not thrown here. 
    Task t1 = DoSomething1Async(someParameter); 

    // rather, it'll get thrown here. this is best practice, 
    // it's what users of Task-returning methods expect. 
    await t1; 

    // if IsNullOrWhiteSpace throws an exception, it will 
    // be thrown here. users will not expect this. 
    Task t2 = DoSomething2Async(someParameter); 

    // this would never have been reached. 
    await t2; 
} 

Wystarczy ilustrujący punkt tutaj - IsNullOrWhiteSpace faktycznie nie rzucać żadnych wyjątków dla jakiegokolwiek powodu.

Jeśli chodzi o śledzenie stosu, ślady stosu asynchronicznego są określane w miejscu, w którym znajduje się await. No await oznacza, że ​​metoda zniknie ze śledzenia stosu.

Powiedz DoSomeExpensiveCheckAsync zgłasza wyjątek. W przypadku DoSomething1Async ślad stosu będzie wyglądał jak caller -> DoSomething1Async -> DoSomeExpensiveCheckAsync.

W przypadku DoSomething2Async, ślad stosu będzie wyglądać tak: caller -> DoSomeExpensiveCheckAsync. W zależności od złożoności kodu może to utrudnić debugowanie.

W praktyce generalnie zwracam tylko bezpośrednio Task, jeśli wiedziałem, że nie zostaną wyrzucone żadne wyjątki, a jeśli nazwa metody byłaby tylko przeciążeniem przekazywania do innego przeciążenia.Zawsze są wyjątki od tej reguły, muszą istnieć miejsca, w których chcesz zmaksymalizować wydajność. Po prostu wybierz i wybierz ostrożnie, zdaj sobie sprawę, że możesz utrudniać życie Tobie i Twojemu użytkownikowi.

Answer 2

To naprawdę nie ma znaczenia. Jeśli masz pewność, że zawsze oznaczasz Task - zwracając metody za pomocą słowa kluczowego async, użyj narzędzia DoSomething1.

Jak pan powiedział, jest to kompromis:

• DoSomething2 nie generuje stan maszyny potrzebne dla metody async i dlatego nieznacznie szybciej (ale różnica jest głównie znikoma).

• Z drugiej strony może to mieć jakieś nieprzewidziane skutki uboczne dotyczące obsługi wyjątków, ponieważ w metodzie async wyjątek będzie przechowywany w zwróconym Task aw drugiej byłoby regularnie wyrzucane.