Tengo un asyncmétodo que no devuelve datos:

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

Llamo a esto desde otro método que devuelve algunos datos:

public string GetStringData()
{
    MyAsyncMethod(); // this generates a warning and swallows exceptions
    return "hello world";
}

Llamar MyAsyncMethod()sin esperar provoca una advertencia " Debido a que esta llamada no se espera, el método actual continúa ejecutándose antes de que se complete la llamada " en Visual Studio. En la página de esa advertencia dice:

Debería considerar suprimir la advertencia solo si está seguro de que no desea esperar a que se complete la llamada asincrónica y que el método llamado no generará ninguna excepción .

Estoy seguro de que no quiero esperar a que se complete la llamada; No necesito ni tengo tiempo para hacerlo. Pero la llamada podría generar excepciones.

Me he topado con este problema varias veces y estoy seguro de que es un problema común que debe tener una solución común.

¿Cómo llamo con seguridad a un método asíncrono sin esperar el resultado?

Actualizar:

Para las personas que sugieren que solo espero el resultado, este es un código que responde a una solicitud web de nuestro servicio web (API web ASP.NET). La espera en un contexto de IU mantiene el subproceso de IU libre, pero en una llamada de solicitud web esperará a que finalice la tarea antes de responder a la solicitud, aumentando así los tiempos de respuesta sin motivo.

Si desea obtener la excepción "asincrónicamente", puede hacer lo siguiente:

  MyAsyncMethod().
    ContinueWith(t => Console.WriteLine(t.Exception),
        TaskContinuationOptions.OnlyOnFaulted);

Esto le permitirá lidiar con una excepción en un hilo que no sea el hilo "principal". Esto significa que no tiene que "esperar" la llamada MyAsyncMethod()desde el hilo que llama MyAsyncMethod; pero aún le permite hacer algo con una excepción, pero solo si ocurre una excepción.

Actualizar:

técnicamente, podrías hacer algo similar con await:

try
{
    await MyAsyncMethod().ConfigureAwait(false);
}
catch (Exception ex)
{
    Trace.WriteLine(ex);
}

... que sería útil si necesita utilizar específicamente try/ catch(o using), pero creo que el ContinueWithser un poco más explícito porque hay que saber qué ConfigureAwait(false)medios.

Primero debe considerar hacer GetStringDataun asyncmétodo y hacer que le awaitdevuelva la tarea MyAsyncMethod.

Si está absolutamente seguro de que no necesita manejar excepciones MyAsyncMethod o saber cuándo se completa, puede hacer esto:

public string GetStringData()
{
  var _ = MyAsyncMethod();
  return "hello world";
}

Por cierto, este no es un "problema común". Es muy raro querer ejecutar algún código y no importa si se completa y no importa si se completa con éxito.

Actualizar:

Dado que está en ASP.NET y desea regresar temprano, puede encontrar útil mi publicación de blog sobre el tema . Sin embargo, ASP.NET no fue diseñado para esto, y no hay garantía de que su código se ejecutará después de que se devuelva la respuesta. ASP.NET hará todo lo posible para que se ejecute, pero no puede garantizarlo.

Entonces, esta es una buena solución para algo simple como lanzar un evento en un registro donde realmente no importa si pierde algunos aquí y allá. No es una buena solución para ningún tipo de operaciones comerciales críticas. En esas situaciones, debe adoptar una arquitectura más compleja, con una forma persistente de guardar las operaciones (por ejemplo, Azure Queues, MSMQ) y un proceso en segundo plano separado (por ejemplo, Azure Worker Role, Win32 Service) para procesarlas.

La respuesta de Peter Ritchie fue lo que quería, y el artículo de Stephen Cleary sobre el regreso temprano en ASP.NET fue muy útil.

Sin embargo, como un problema más general (no específico de un contexto ASP.NET), la siguiente aplicación de consola muestra el uso y el comportamiento de la respuesta de Peter usando Task.ContinueWith(...)

static void Main(string[] args)
{
  try
  {
    // output "hello world" as method returns early
    Console.WriteLine(GetStringData());
  }
  catch
  {
    // Exception is NOT caught here
  }
  Console.ReadLine();
}

public static string GetStringData()
{
  MyAsyncMethod().ContinueWith(OnMyAsyncMethodFailed, TaskContinuationOptions.OnlyOnFaulted);
  return "hello world";
}

public static async Task MyAsyncMethod()
{
  await Task.Run(() => { throw new Exception("thrown on background thread"); });
}

public static void OnMyAsyncMethodFailed(Task task)
{
  Exception ex = task.Exception;
  // Deal with exceptions here however you want
}

GetStringData()regresa temprano sin esperar MyAsyncMethod()y las excepciones incluidas MyAsyncMethod()se tratan en OnMyAsyncMethodFailed(Task task)y no en try/ catchalrededorGetStringData()

Termino con esta solución:

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

public string GetStringData()
{
    // Run async, no warning, exception are catched
    RunAsync(MyAsyncMethod()); 
    return "hello world";
}

private void RunAsync(Task task)
{
    task.ContinueWith(t =>
    {
        ILog log = ServiceLocator.Current.GetInstance<ILog>();
        log.Error("Unexpected Error", t.Exception);

    }, TaskContinuationOptions.OnlyOnFaulted);
}

Esto se llama disparar y olvidar, y hay una extensión para eso.

Consume una tarea y no hace nada con ella. Útil para disparar y olvidar llamadas a métodos asincrónicos dentro de métodos asincrónicos.

Instalar paquete nuget .

Utilizar:

MyAsyncMethod().Forget();

Supongo que surge la pregunta, ¿por qué necesitarías hacer esto? La razón asyncen C # 5.0 es para que pueda esperar un resultado. Este método no es realmente asíncrono, sino que simplemente se llama a la vez para no interferir demasiado con el hilo actual.

Quizás sea mejor comenzar un hilo y dejar que termine solo.

En tecnologías con bucles de mensajes (no estoy seguro si ASP es uno de ellos), puede bloquear el bucle y procesar los mensajes hasta que finalice la tarea, y usar ContinueWith para desbloquear el código:

public void WaitForTask(Task task)
{
    DispatcherFrame frame = new DispatcherFrame();
    task.ContinueWith(t => frame.Continue = false));
    Dispatcher.PushFrame(frame);
}

Este enfoque es similar al bloqueo en ShowDialog y sigue manteniendo la interfaz de usuario receptiva.

Llego tarde a la fiesta aquí, pero hay una biblioteca increíble que he estado usando y que no he visto referenciada en las otras respuestas

https://github.com/brminnick/AsyncAwaitBestPractices

Si necesita "disparar y olvidar", llame al método de extensión en la tarea.

Pasar la acción onException a la llamada asegura que obtenga lo mejor de ambos mundos, sin necesidad de esperar la ejecución y ralentizar a sus usuarios, al tiempo que conserva la capacidad de manejar la excepción de manera elegante.

En su ejemplo, lo usaría así:

   public string GetStringData()
    {
        MyAsyncMethod().SafeFireAndForget(onException: (exception) =>
                    {
                      //DO STUFF WITH THE EXCEPTION                    
                    }); 
        return "hello world";
    }

También proporciona los AsyncCommands esperados que implementan ICommand de fábrica, lo que es excelente para mi solución MVVM Xamarin

La solución es iniciar el HttpClient en otra tarea de ejecución sin contexto de sincronización:

var submit = httpClient.PostAsync(uri, new StringContent(body, Encoding.UTF8,"application/json"));
var t = Task.Run(() => submit.ConfigureAwait(false));
await t.ConfigureAwait(false);

Si realmente quieres hacer esto. Solo para abordar "Llamar a un método asincrónico en C # sin esperar", puede ejecutar el método asincrónico dentro de a Task.Run. Este enfoque esperará hasta el MyAsyncMethodfinal.

public string GetStringData()
{
    Task.Run(()=> MyAsyncMethod()).Result;
    return "hello world";
}

awaitdesenvuelve asincrónicamente la Resulttarea, mientras que solo usando Result se bloquearía hasta que la tarea se hubiera completado.

Por lo general, el método asíncrono devuelve la clase de tarea. Si usa un Wait()método o Resultpropiedad y el código arroja una excepción (el tipo de excepción se envuelve) AggregateException, entonces debe consultar Exception.InnerExceptionpara localizar la excepción correcta.

Pero también es posible usarlo .GetAwaiter().GetResult(): también esperará la tarea asincrónica, pero no envolverá la excepción.

Así que aquí hay un breve ejemplo:

public async Task MyMethodAsync()
{
}

public string GetStringData()
{
    MyMethodAsync().GetAwaiter().GetResult();
    return "test";
}

Es posible que también desee poder devolver algunos parámetros de la función asincrónica, lo que se puede lograr al proporcionar una Action<return type>función asincrónica adicional , por ejemplo, así:

public string GetStringData()
{
    return MyMethodWithReturnParameterAsync().GetAwaiter().GetResult();
}

public async Task<String> MyMethodWithReturnParameterAsync()
{
    return "test";
}

Tenga en cuenta que los métodos asíncronos generalmente tienen ASyncnombres de sufijos, solo para evitar la colisión entre funciones de sincronización con el mismo nombre. (Por ejemplo FileStream.ReadAsync): he actualizado los nombres de las funciones para seguir esta recomendación.