async / waitit - quando restituire un task vs vuoto?

In quali scenari si vorrebbe usare

public async Task AsyncMethod(int num)

invece di

public async void AsyncMethod(int num)

L'unico scenario a cui riesco a pensare è se hai bisogno dell'attività per poterne monitorare i progressi.

Inoltre, nel seguente metodo, le parole chiave asincrone e in attesa sono inutili?

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

1) Normalmente, si vorrebbe restituire a Task. L'eccezione principale dovrebbe essere quando è necessario disporre di un voidtipo di ritorno (per eventi). Se non c'è motivo di non consentire al chiamante di awaitsvolgere il proprio compito, perché non consentirlo?

2) i asyncmetodi che restituiscono voidsono speciali in un altro aspetto: rappresentano operazioni asincrone di alto livello e hanno regole aggiuntive che entrano in gioco quando l'attività restituisce un'eccezione. Il modo più semplice per mostrare la differenza è con un esempio:

static async void f()
{
    await h();
}

static async Task g()
{
    await h();
}

static async Task h()
{
    throw new NotImplementedException();
}

private void button1_Click(object sender, EventArgs e)
{
    f();
}

private void button2_Click(object sender, EventArgs e)
{
    g();
}

private void button3_Click(object sender, EventArgs e)
{
    GC.Collect();
}

fL 'eccezione è sempre "osservata". Un'eccezione che lascia un metodo asincrono di livello superiore viene semplicemente trattata come qualsiasi altra eccezione non gestita. gL 'eccezione non viene mai osservata. Quando il Garbage Collector arriva per ripulire l'attività, vede che l'attività ha provocato un'eccezione e nessuno ha gestito l'eccezione. Quando ciò accade, il TaskScheduler.UnobservedTaskExceptiongestore esegue. Non dovresti mai lasciare che ciò accada. Per usare il tuo esempio,

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

Sì, usa asynce awaitqui, assicurano che il tuo metodo funzioni ancora correttamente se viene generata un'eccezione.

per ulteriori informazioni, consultare: http://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Ho trovato questo articolo molto utile su asynce voidscritto da Jérôme Laban: https://jaylee.org/archive/2012/07/08/c-sharp-async-tips-and-tricks-part-2-async-void .html

La linea di fondo è che si async+voidpuò bloccare il sistema e di solito dovrebbe essere usato solo sui gestori di eventi lato UI.

Il motivo alla base di ciò è il contesto di sincronizzazione utilizzato da AsyncVoidMethodBuilder, che non è presente in questo esempio. Quando non esiste un contesto di sincronizzazione ambientale, qualsiasi eccezione non gestita dal corpo di un metodo vuoto asincrono viene riproposta sul ThreadPool. Mentre apparentemente non esiste un altro luogo logico in cui si possa generare quel tipo di eccezione non gestita, lo sfortunato effetto è che il processo è stato terminato, poiché le eccezioni non gestite su ThreadPool terminano effettivamente il processo da .NET 2.0. È possibile intercettare tutte le eccezioni non gestite utilizzando l'evento AppDomain.UnhandledException, ma non è possibile ripristinare il processo da questo evento.

Quando si scrivono i gestori di eventi dell'interfaccia utente, i metodi del vuoto asincrono sono in qualche modo indolori perché le eccezioni vengono trattate allo stesso modo dei metodi non asincroni; vengono gettati sul Dispatcher. Esiste la possibilità di recuperare da tali eccezioni, con è più che corretto per la maggior parte dei casi. Al di fuori dei gestori di eventi dell'interfaccia utente, tuttavia, i metodi del vuoto asincrono sono in qualche modo pericolosi da usare e potrebbero non essere così facili da trovare.

Ho avuto un'idea chiara da queste affermazioni.

1. I metodi void asincroni hanno una semantica di gestione degli errori diversa. Quando viene generata un'eccezione da un'attività asincrona o da un metodo dell'attività asincrona, tale eccezione viene acquisita e posizionata sull'oggetto Task. Con i metodi void asincroni, non esiste alcun oggetto Task, quindi eventuali eccezioni generate da un metodo void asincrono verranno sollevate direttamente su SynchronizationContext (SynchronizationContext rappresenta una posizione "dove" potrebbe essere eseguito il codice) che era attiva quando il metodo vuoto asincrono iniziato

Le eccezioni da un metodo Async Void non possono essere prese con Catch

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

Queste eccezioni possono essere osservate utilizzando AppDomain.UnhandledException o un simile evento catch-all per le applicazioni GUI / ASP.NET, ma l'utilizzo di tali eventi per la gestione regolare delle eccezioni è una ricetta per la non manutenibilità (arresta in modo anomalo l'applicazione).

2. I metodi del vuoto asincrono hanno una semantica di composizione diversa. I metodi asincroni che restituiscono Task o Task possono essere facilmente composti utilizzando wait, Task.WhenAny, Task.WhenAll e così via. I metodi asincroni che restituiscono void non forniscono un modo semplice per notificare il codice chiamante che hanno completato. È facile avviare diversi metodi di vuoto asincrono, ma non è facile determinare quando hanno finito. I metodi nulli asincroni avviseranno il loro SynchronizationContext quando iniziano e finiscono, ma un SynchronizationContext personalizzato è una soluzione complessa per il normale codice dell'applicazione.

3. Metodo Async Void utile quando si utilizza il gestore di eventi sincrono perché aumentano le loro eccezioni direttamente su SynchronizationContext, che è simile al comportamento dei gestori di eventi sincroni

Per maggiori dettagli controlla questo link https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Il problema con la chiamata del vuoto asincrono è che non riesci nemmeno a recuperare l'attività, non hai modo di sapere quando l'attività della funzione è stata completata (vedi https://blogs.msdn.microsoft.com/oldnewthing/20170720-00/ ? p = 96655 )

Ecco i tre modi per chiamare una funzione asincrona:

async Task<T> SomethingAsync() { ... return t; }
async Task SomethingAsync() { ... }
async void SomethingAsync() { ... }

In tutti i casi, la funzione si trasforma in una catena di attività. La differenza è ciò che restituisce la funzione.

Nel primo caso, la funzione restituisce un'attività che alla fine produce t.

Nel secondo caso, la funzione restituisce un'attività che non ha prodotto, ma è comunque possibile attendere per sapere quando è stata completata.

Il terzo caso è quello cattivo. Il terzo caso è come il secondo caso, tranne per il fatto che non è nemmeno possibile recuperare l'attività. Non hai modo di sapere quando l'attività della funzione è stata completata.

Il caso del vuoto asincrono è un "fuoco e dimentica": inizi la catena di attività, ma non ti importa quando è finita. Quando la funzione ritorna, tutto ciò che sai è che tutto fino alla prima attesa è stato eseguito. Tutto ciò che segue la prima attesa verrà eseguito in futuro in un punto non specificato a cui non si ha accesso.

Penso che tu possa usare anche async voidper dare il via alle operazioni in background, purché tu stia attento a cogliere le eccezioni. Pensieri?

class Program {

    static bool isFinished = false;

    static void Main(string[] args) {

        // Kick off the background operation and don't care about when it completes
        BackgroundWork();

        Console.WriteLine("Press enter when you're ready to stop the background operation.");
        Console.ReadLine();
        isFinished = true;
    }

    // Using async void to kickoff a background operation that nobody wants to be notified about when it completes.
    static async void BackgroundWork() {
        // It's important to catch exceptions so we don't crash the appliation.
        try {
            // This operation will end after ten interations or when the app closes. Whichever happens first.
            for (var count = 1; count <= 10 && !isFinished; count++) {
                await Task.Delay(1000);
                Console.WriteLine($"{count} seconds of work elapsed.");
            }
            Console.WriteLine("Background operation came to an end.");
        } catch (Exception x) {
            Console.WriteLine("Caught exception:");
            Console.WriteLine(x.ToString());
        }
    }
}

La mia risposta è semplice: non puoi aspettare il metodo vuoto

Error   CS4008  Cannot await 'void' TestAsync   e:\test\TestAsync\TestAsyncProgram.cs

Quindi, se il metodo è asincrono, è meglio essere attendibili, perché si può perdere il vantaggio asincrono.

Secondo la documentazione Microsoft , non dovrebbe MAI utilizzareasync void

Non fare ciò: L'esempio seguente usa ciò async voidche rende completa la richiesta HTTP quando viene raggiunta la prima attesa:

• Che è SEMPRE una cattiva pratica nelle app ASP.NET Core.

• Accede a HttpResponse al termine della richiesta HTTP.

• Si blocca il processo.