Czy można zadeklarować metodę asynchroniczną jako zwracającą pustkę, aby uciszyć ostrzeżenie CS4014?

Question

Program Visual Studio wysyła ostrzeżenie dotyczące tego kodu ("ponieważ wywołanie to nie jest oczekiwane, wykonanie bieżącej metody jest kontynuowane przed zakończeniem połączenia").

static void Main(string[] args) 
{ 
    FireAndForget(); // <-- Warning CS4014 
    // Do something else. 
} 

static async Task FireAndForget() 
{ 
    // Do something (cannot throw). 
} 

moim rozumieniu jest to, że jest OK, aby nie czekać do tego zadania w tym konkretnym przypadku, ponieważ fire-and-forget nigdy rzuci wyjątek.

Zamiast wyłączać ostrzeżenie z pragmą, rozważałem zmianę typu powrotu FireAndForget z zadania na nieważne. To skutecznie wycisza kompilator.

static async void FireAndForget() // <-- Task changed to void 
{ 
    // Do something (cannot throw). 
} 

Jednak według Stephen Cleary „asynchroniczny” void metod należy unikać, więc nie jestem pewien, co zrobić.

Czy można mieć metodę "async void", jeśli metoda nie została zaprojektowana jako pierwsza i jeśli nie zostanie zgłoszony żaden wyjątek?

Answer 1

Niezwykle trudno jest uzyskać prawdziwą operację przeciwpożarową; to jest operacja, w której:

• Nikt nie dba o to, kiedy się zakończy.
• Nikt się nie przejmuje, jeśli się uda.
• Nikt się nie przejmuje, jeśli zgłasza wyjątek.

Zwłaszcza z ostatnią z nich; większość tak zwanych operacji "pożegnaj i zapomnij" nie jest w rzeczywistości pożarem i zapomnieniem, ponieważ trzeba podjąć pewne działania, jeśli się to nie uda.

To powiedziawszy, jest kilka sytuacji, w których można zastosować prawdziwy ogień i zapomnieć.

wolę używać async Task i uniknąć ostrzeżenia kompilatora przypisując zadanie inaczej nieużywanego zmiennej:

var _ = FireAndForget(); 

async Task metody są bardziej wielokrotnego użytku i sprawdzalne niż async void metod.

Jednak nie zgodziłbym się, gdyby programista z mojego zespołu użył zamiast tego async void.

Answer 2

Czy można mieć „asynchronicznej void” metodę jeżeli metoda nie jest przeznaczony być awaitable w pierwszej kolejności, a jeśli nie zostanie wyrzucony wyjątek?

Chociaż może być "OK", aby to zrobić, nadal zachęcam do wykonania metody async Task. Nawet jeśli jesteś w 100% pewny, że ta metoda nie zostanie rzucona i nie jest oczekiwana, nigdy nie wiesz, jak to się skończy. Teraz już w pełni zdajesz sobie sprawę, jakie są konsekwencje używania async void, ale jeśli istnieje niewielka szansa, że ​​ktoś może potrzebować tego użyć w przyszłości, lepiej jest umieścić komentarz na temat tego, dlaczego ten Task nie jest oczekiwano, zamiast iść z łatwą ścieżką tworzenia tego void.

Nie pozwól, aby ostrzeżenia kompilatora martwiły Cię, powiedziałbym, że martwisz się poprawnością i skutkami, jakie może to mieć w Twoim kodzie.

Answer 3

Jednym z potencjalnych problemów jest to, że nie będzie można stwierdzić, czy kod wyłączył wyjątek, czy nie. Więc jeśli masz testy jednostkowe w celu ich wykrycia, testy jednostkowe nigdy nie będą działać.

Klasyczny przykład ze strony MSDN:

 
private async void ThrowExceptionAsync() 
{ 
    throw new InvalidOperationException(); 
} 
public void AsyncVoidExceptions_CannotBeCaughtByCatch() 
{ 
    try 
    { 
    ThrowExceptionAsync(); 
    } 
    catch (Exception) 
    { 
    // The exception is never caught here! 
    throw; 
    } 
} 

http://haacked.com/archive/2014/11/11/async-void-methods/

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Zamiast async void, czy jest to przypadek szczególny krawędź, jak o użyciu instrukcji PRAGMA?

#pragma warning disable CS-4014 
... your code here ... 
#pragma warning restore CS-4014 

W ten sposób można wyłączyć zakłócenia statyczne.

HTH ...