Soppressione "avviso CS4014: poiché questa chiamata non è attesa, l'esecuzione del metodo corrente continua ..."

Questo non è un duplicato di "Come chiamare in modo sicuro un metodo asincrono in C # senza attendere" .

Come sopprimo bene il seguente avviso?

avviso CS4014: poiché questa chiamata non è attesa, l'esecuzione del metodo corrente continua prima del completamento della chiamata. Valuta la possibilità di applicare l'operatore "wait" al risultato della chiamata.

Un semplice esempio:

static async Task WorkAsync()
{
    await Task.Delay(1000);
    Console.WriteLine("Done!");
}

static async Task StartWorkAsync()
{
    WorkAsync(); // I want fire-and-forget 

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

Cosa ho provato e non mi è piaciuto:

static async Task StartWorkAsync()
{
    #pragma warning disable 4014
    WorkAsync(); // I want fire-and-forget here
    #pragma warning restore 4014
    // ...
}

static async Task StartWorkAsync()
{
    var ignoreMe = WorkAsync(); // I want fire-and-forget here
    // ...
}

Aggiornato , poiché la risposta originale accettata è stata modificata, ho modificato la risposta accettata a quella usando gli scarti di C # 7.0 , poiché non credo ContinueWithsia appropriato qui. Ogni volta che ho bisogno di registrare le eccezioni per le operazioni antincendio e dimentico, uso qui un approccio più elaborato proposto da Stephen Cleary .

Con C # 7 ora puoi usare gli scarti :

_ = WorkAsync();

È possibile creare un metodo di estensione che impedirà l'avviso. Il metodo di estensione può essere vuoto o è possibile aggiungere la gestione delle eccezioni con .ContinueWith()lì.

static class TaskExtensions
{
    public static void Forget(this Task task)
    {
        task.ContinueWith(
            t => { WriteLog(t.Exception); },
            TaskContinuationOptions.OnlyOnFaulted);
    }
}

public async Task StartWorkAsync()
{
    this.WorkAsync().Forget();
}

Tuttavia ASP.NET conta il numero di attività in esecuzione, quindi non funzionerà con l' Forget()estensione semplice come elencato sopra e invece potrebbe non riuscire con l'eccezione:

Un modulo o gestore asincrono completato mentre un'operazione asincrona era ancora in sospeso.

Con .NET 4.5.2 può essere risolto usando HostingEnvironment.QueueBackgroundWorkItem:

public static Task HandleFault(this Task task, CancellationToken cancelToken)
{
    return task.ContinueWith(
        t => { WriteLog(t.Exception); },
        cancelToken,
        TaskContinuationOptions.OnlyOnFaulted,
        TaskScheduler.Default);
}

public async Task StartWorkAsync()
{
    System.Web.Hosting.HostingEnvironment.QueueBackgroundWorkItem(
        cancelToken => this.WorkAsync().HandleFault(cancelToken));
}

Puoi decorare il metodo con il seguente attributo:

[System.Diagnostics.CodeAnalysis.SuppressMessage("Await.Warning", "CS4014:Await.Warning")]
static async Task StartWorkAsync()
{
    WorkAsync();
    // ...
}

Fondamentalmente stai dicendo al compilatore che sai cosa stai facendo e non ha bisogno di preoccuparsi di possibili errori.

La parte importante di questo codice è il secondo parametro. La parte "CS4014:" è ciò che sopprime l'avviso. Puoi scrivere tutto quello che vuoi sul resto.

Il mio modo doppio di affrontarlo.

Salvalo in una variabile di scarto (C # 7)

Esempio

_ = Task.Run(() => DoMyStuff()).ConfigureAwait(false);

Dall'introduzione dei rigetti in C # 7, ora ritengo che sia meglio che sopprimere l'avvertimento. Perché non solo sopprime l'avvertimento, ma rende anche chiara l'intenzione di fuoco e dimentica.

Inoltre, il compilatore sarà in grado di ottimizzarlo in modalità di rilascio.

Sopprimilo e basta

#pragma warning disable 4014
...
#pragma warning restore 4014

è una soluzione abbastanza piacevole per "sparare e dimenticare".

Il motivo per cui esiste questo avviso è perché in molti casi non è tua intenzione utilizzare un metodo che restituisce attività senza attenderlo. Sopprimere l'avviso quando si intende sparare e dimenticare ha senso.

Se hai difficoltà a ricordare come si scrive #pragma warning disable 4014, lascia che Visual Studio lo aggiunga per te. Premi Ctrl +. per aprire "Azioni rapide" e quindi "Sopprimi CS2014"

Tutto sommato

È stupido creare un metodo che richiede qualche spunta in più per essere eseguito, allo scopo di sopprimere un avviso.

Un modo semplice per interrompere l'avviso è semplicemente assegnare l'attività quando la si chiama:

Task fireAndForget = WorkAsync(); // No warning now

E così nel tuo post originale faresti:

static async Task StartWorkAsync()
{
    // Fire and forget
    var fireAndForget = WorkAsync(); // Tell the compiler you know it's a task that's being returned 

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

Il motivo dell'avviso è che WorkAsync sta restituendo a Task che non viene mai letto o atteso. È possibile impostare il tipo di restituzione di WorkAsync su voide l'avviso scomparirà.

In genere un metodo restituisce a Taskquando il chiamante deve conoscere lo stato del lavoratore. Nel caso di un incendio e dimentica, il vuoto dovrebbe essere restituito per assomigliare al fatto che il chiamante è indipendente dal metodo chiamato.

static async void WorkAsync()
{
    await Task.Delay(1000);
    Console.WriteLine("Done!");
}

static async Task StartWorkAsync()
{
    WorkAsync(); // no warning since return type is void

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

Perché non avvolgerlo in un metodo asincrono che restituisce il vuoto? Un po 'lungo ma vengono utilizzate tutte le variabili.

static async Task StartWorkAsync()
{   
     async void WorkAndForgetAsync() => await WorkAsync();
     WorkAndForgetAsync(); // no warning
}

Ho trovato questo approccio per caso oggi. È possibile definire un delegato e assegnare prima il metodo asincrono al delegato.

    delegate Task IntermediateHandler();



    static async Task AsyncOperation()
    {
        await Task.Yield();
    }

e chiamalo così

(new IntermediateHandler(AsyncOperation))();

...

Ho pensato che fosse interessante che il compilatore non avesse dato lo stesso avvertimento quando si utilizzava il delegato.