Хороше рішення для await у try / catch / нарешті?

Мені потрібно викликати asyncметод у catchблоці, перш ніж знову викидати виняток (з його трасуванням стека), як це:

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

Але, на жаль, ви не можете використовувати awaitа catchчи finallyблок. Я дізнався, що це тому, що компілятор не має способу повернутися назад у catchблок, щоб виконати те, що є після вашої awaitінструкції або щось подібне ...

Я намагався використати Task.Wait()для заміни, awaitі я отримав глухий кут. Я шукав в Інтернеті, як мені цього уникнути, і знайшов цей сайт .

Оскільки я не можу змінити asyncметоди, і я не знаю, чи використовують вони ConfigureAwait(false), я створив ці методи, які беруть Func<Task>метод, який запускає асинхронний метод, коли ми потрапляємо в інший потік (щоб уникнути тупикової ситуації), і чекає його завершення:

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());
}

Тож мої запитання: Чи вважаєте ви, що цей код нормальний?

Звичайно, якщо у вас є якісь вдосконалення або ви знаєте кращий підхід, я слухаю! :)

Ви можете перемістити логіку за межі catchблоку та відновити виняток після, якщо потрібно, за допомогою 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();
    }
}

Таким чином, коли абонент перевіряє StackTraceвластивість винятку , він все одно фіксує, куди TaskThatFailsвоно було кинуте.

Ви повинні знати, що, починаючи з C # 6.0, його можна використовувати awaitв catchта finallyблоках, тому ви можете насправді зробити це:

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

Нова C # 6.0 особливості, в тому числі той , який я тільки що згадав , перераховані тут , або як відео тут .

Якщо вам потрібно скористатися asyncобробниками помилок, я рекомендую щось подібне:

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

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

Проблема синхронної блокування asyncкоду (незалежно від того, на якому потоці він запущений) полягає в тому, що ви синхронно блокуєте. У більшості сценаріїв краще використовувати await.

Оновлення: Оскільки вам потрібно переробити, ви можете використовувати ExceptionDispatchInfo.

Ми витягли чудову відповідь hvd на наступний клас корисних програм багаторазового використання у нашому проекті:

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();
            }
        }
    }
}

Можна було б використовувати його наступним чином:

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

Не соромтеся вдосконалювати імена, ми дотримувались навмисно багатослівно. Зауважте, що немає необхідності фіксувати контекст всередині обгортки, оскільки він уже захоплений на сайті виклику, отже ConfigureAwait(false).