Diferencia entre await y ContinueWith

Aquí está la secuencia de fragmentos de código que utilicé recientemente para ilustrar la diferencia y varios problemas que se solucionan usando soluciones asincrónicas.

Supongamos que tiene algún controlador de eventos en su aplicación basada en GUI que toma mucho tiempo, y por lo que le gustaría hacerlo asincrónico. Aquí está la lógica síncrona con la que comienzas:

while (true) {
    string result = LoadNextItem().Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
        break;
    }
}

LoadNextItem devuelve una Tarea, que eventualmente producirá algún resultado que le gustaría inspeccionar. Si el resultado actual es el que estás buscando, actualizas el valor de algún contador en la interfaz de usuario, y volver desde el método. De lo contrario, continuará procesando más elementos de LoadNextItem.

Primera idea para la versión asíncrona: ¡solo usa continuaciones! Y vamos a ignorar la parte de bucle por el momento. Quiero decir, ¿qué podría salir mal?

return LoadNextItem().ContinueWith(t => {
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
});

Genial, ahora tenemos un método que no bloquea! Se bloquea en su lugar. Cualquier actualización de los controles de la interfaz de usuario debe ocurrir en el subproceso de la interfaz de usuario, por lo que deberá tener en cuenta eso. Afortunadamente, hay una opción para especificar cómo deben programarse las continuaciones, y hay una opción predeterminada para esto:

return LoadNextItem().ContinueWith(t => {
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
},
TaskScheduler.FromCurrentSynchronizationContext());

Genial, ahora tenemos un método que no se bloquea! En su lugar, falla silenciosamente. Las continuaciones son tareas separadas en sí mismas, con su estatus no ligado al de la tarea antecedente. Por lo tanto, incluso si LoadNextItem falla, la persona que llama solo verá una tarea que se haya completado con éxito. Bien, entonces solo pasa la excepción, si hay una:

return LoadNextItem().ContinueWith(t => {
    if (t.Exception != null) {
        throw t.Exception.InnerException;
    }
    string result = t.Result;
    if (result.Contains("target")) {
        Counter.Value = result.Length;
    }
},
TaskScheduler.FromCurrentSynchronizationContext());

Genial, ahora esto en realidad funciona. Para un solo artículo. Ahora, qué tal ese bucle. Resulta que una solución equivalente a la lógica de la versión síncrona original se verá algo como esto:

Task AsyncLoop() {
    return AsyncLoopTask().ContinueWith(t =>
        Counter.Value = t.Result,
        TaskScheduler.FromCurrentSynchronizationContext());
}
Task<int> AsyncLoopTask() {
    var tcs = new TaskCompletionSource<int>();
    DoIteration(tcs);
    return tcs.Task;
}
void DoIteration(TaskCompletionSource<int> tcs) {
    LoadNextItem().ContinueWith(t => {
        if (t.Exception != null) {
            tcs.TrySetException(t.Exception.InnerException);
        } else if (t.Result.Contains("target")) {
            tcs.TrySetResult(t.Result.Length);
        } else {
            DoIteration(tcs);
        }});
}

O, en lugar de todo lo anterior, puedes usar async para hacer lo mismo:

async Task AsyncLoop() {
    while (true) {
        string result = await LoadNextItem();
        if (result.Contains("target")) {
            Counter.Value = result.Length;
            break;
        }
    }
}

Eso es mucho mejor ahora, ¿no?