Uma boa solução para esperar em try / catch / finally?

Preciso chamar um asyncmétodo em um catchbloco antes de lançar novamente a exceção (com seu rastreamento de pilha) como este:

try
{
    // Do something
}
catch
{
    // <- Clean things here with async methods
    throw;
}

Mas, infelizmente, você não pode usar awaitem um bloco catchou finally. Aprendi que é porque o compilador não tem como voltar em um catchbloco para executar o que está depois de sua awaitinstrução ou algo assim ...

Tentei usar Task.Wait()para substituir awaite obtive um impasse. Pesquisei na Web como poderia evitar isso e encontrei este site .

Como não posso alterar os asyncmétodos nem sei se eles usam ConfigureAwait(false), criei esses métodos que usam um Func<Task>que inicia um método assíncrono quando estamos em um thread diferente (para evitar um deadlock) e aguarda sua conclusão:

public static void AwaitTaskSync(Func<Task> action)
{
    Task.Run(async () => await action().ConfigureAwait(false)).Wait();
}

public static TResult AwaitTaskSync<TResult>(Func<Task<TResult>> action)
{
    return Task.Run(async () => await action().ConfigureAwait(false)).Result;
}

public static void AwaitSync(Func<IAsyncAction> action)
{
    AwaitTaskSync(() => action().AsTask());
}

public static TResult AwaitSync<TResult>(Func<IAsyncOperation<TResult>> action)
{
    return AwaitTaskSync(() => action().AsTask());
}

Portanto, minhas perguntas são: Você acha que este código está correto?

Claro, se você tiver algumas melhorias ou conhecer uma abordagem melhor, estou ouvindo! :)

Você pode mover a lógica para fora do catchbloco e relançar a exceção depois, se necessário, usando ExceptionDispatchInfo.

static async Task f()
{
    ExceptionDispatchInfo capturedException = null;
    try
    {
        await TaskThatFails();
    }
    catch (MyException ex)
    {
        capturedException = ExceptionDispatchInfo.Capture(ex);
    }

    if (capturedException != null)
    {
        await ExceptionHandler();

        capturedException.Throw();
    }
}

Dessa forma, quando o chamador inspeciona a StackTracepropriedade da exceção , ele ainda registra onde TaskThatFailsela foi lançada.

Você deve saber que, desde o C # 6.0, é possível usar blocos awaitin catche finally, portanto, você pode fazer o seguinte:

try
{
    // Do something
}
catch (Exception ex)
{
    await DoCleanupAsync();
    throw;
}

Os novos recursos do C # 6.0, incluindo o que acabei de mencionar, estão listados aqui ou como um vídeo aqui .

Se você precisar usar asyncgerenciadores de erros, recomendo algo assim:

Exception exception = null;
try
{
  ...
}
catch (Exception ex)
{
  exception = ex;
}

if (exception != null)
{
  ...
}

O problema com o bloqueio síncrono no asynccódigo (independentemente do thread em que esteja sendo executado) é que você está bloqueando de forma síncrona. Na maioria dos cenários, é melhor usar await.

Atualização: Já que você precisa relançar, você pode usar ExceptionDispatchInfo.

Extraímos grande resposta do hvd para a seguinte classe de utilitário reutilizável em nosso projeto:

public static class TryWithAwaitInCatch
{
    public static async Task ExecuteAndHandleErrorAsync(Func<Task> actionAsync,
        Func<Exception, Task<bool>> errorHandlerAsync)
    {
        ExceptionDispatchInfo capturedException = null;
        try
        {
            await actionAsync().ConfigureAwait(false);
        }
        catch (Exception ex)
        {
            capturedException = ExceptionDispatchInfo.Capture(ex);
        }

        if (capturedException != null)
        {
            bool needsThrow = await errorHandlerAsync(capturedException.SourceException).ConfigureAwait(false);
            if (needsThrow)
            {
                capturedException.Throw();
            }
        }
    }
}

Seria usado da seguinte maneira:

    public async Task OnDoSomething()
    {
        await TryWithAwaitInCatch.ExecuteAndHandleErrorAsync(
            async () => await DoSomethingAsync(),
            async (ex) => { await ShowMessageAsync("Error: " + ex.Message); return false; }
        );
    }

Sinta-se à vontade para melhorar a nomenclatura, nós o mantivemos intencionalmente prolixo. Observe que não há necessidade de capturar o contexto dentro do wrapper, pois ele já está capturado no site da chamada, portanto ConfigureAwait(false).