Правильний спосіб боротьби з винятками в AsyncDispose

Під час переходу на новий .NET Core 3 IAsynsDisposable, я натрапив на наступну проблему.

Суть проблеми: якщо DisposeAsyncкидає виняток, цей виняток приховує будь-які винятки, кинуті всередину await using-блок.

class Program 
{
    static async Task Main()
    {
        try
        {
            await using (var d = new D())
            {
                throw new ArgumentException("I'm inside using");
            }
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message); // prints I'm inside dispose
        }
    }
}

class D : IAsyncDisposable
{
    public async ValueTask DisposeAsync()
    {
        await Task.Delay(1);
        throw new Exception("I'm inside dispose");
    }
}

Що потрапляє - це AsyncDisposeвилучення, якщо воно кинене, і виняток зсередини, await usingлише якщо AsyncDisposeвін не кидає.

Однак я б вважав за краще навпаки: отримати виняток із await usingблоку, якщо це можливо, та DisposeAsync-виключити, лише якщо await usingблок успішно закінчився.

Обгрунтування: Уявіть, що мій клас Dпрацює з деякими мережевими ресурсами і підписується на деякі сповіщення віддалено. Код всередині await usingможе зробити щось не так і провалити канал зв'язку, після чого код у програмі Dispose, який намагається граціозно закрити зв’язок (наприклад, скасувати підписку на сповіщення), теж не вдасться. Але перший виняток дає мені реальну інформацію про проблему, а другий - лише вторинну проблему.

В іншому випадку, коли основна частина пробіглась, а знешкодження не вдалося, справжня проблема знаходиться всередині DisposeAsync, тож виняток із DisposeAsyncвідповідної. Це означає, що придушення всіх винятків всередині DisposeAsyncне повинно бути доброю ідеєю.

Я знаю, що існує однакова проблема із випадком, що не стосується асинхронізації: виняток finallyзаміняє виняток у try, тому не рекомендується запускати їх Dispose(). Але з класами доступу до мережі придушення винятків у методах закриття зовсім не виглядає добре.

Можна вирішити проблему за допомогою наступного помічника:

static class AsyncTools
{
    public static async Task UsingAsync<T>(this T disposable, Func<T, Task> task)
            where T : IAsyncDisposable
    {
        bool trySucceeded = false;
        try
        {
            await task(disposable);
            trySucceeded = true;
        }
        finally
        {
            if (trySucceeded)
                await disposable.DisposeAsync();
            else // must suppress exceptions
                try { await disposable.DisposeAsync(); } catch { }
        }
    }
}

і використовувати його як

await new D().UsingAsync(d =>
{
    throw new ArgumentException("I'm inside using");
});

який є некрасивим (і забороняє такі речі, як раннє повернення всередину використовуючого блоку).

Чи є добре, канонічне рішення, await usingякщо це можливо? Мій пошук в Інтернеті не знайшов навіть обговорення цієї проблеми.

Є винятки, які ви хочете вивести на поверхню (перервати поточний запит або збити процес), і є винятки, що ваш дизайн очікується, що трапляються іноді, і ви можете впоратися з ними (наприклад, повторити і продовжити).

Але розрізняти ці два типи - до остаточного абонента коду - це вся суть винятків, щоб рішення залишати за викликом.

Іноді абонент надає більший пріоритет розкриттю винятку з вихідного кодового блоку, а іноді винятку з Dispose. Не існує загального правила вирішення питання, яке має мати пріоритет. CLR принаймні відповідає (як ви зазначали) між поведінкою синхронізації та неасинхронізацією.

Можливо, прикро, що зараз ми маємо AggregateExceptionпредставляти кілька винятків, і це не може бути дооснащено для вирішення цього питання. тобто, якщо виняток вже є в польоті, а інший кинуто, вони об'єднуються в AggregateException. catchМеханізм може бути змінений таким чином , що якщо ви пишете catch (MyException)то зловить , AggregateExceptionщо включає в себе виключення типу MyException. Однак, з цієї ідеї є різні інші ускладнення, і зараз, мабуть, занадто ризиковано модифікувати щось таке принципове.

Ви можете покращити свою UsingAsyncпідтримку якнайшвидшого повернення вартості:

public static async Task<R> UsingAsync<T, R>(this T disposable, Func<T, Task<R>> task)
        where T : IAsyncDisposable
{
    bool trySucceeded = false;
    R result;
    try
    {
        result = await task(disposable);
        trySucceeded = true;
    }
    finally
    {
        if (trySucceeded)
            await disposable.DisposeAsync();
        else // must suppress exceptions
            try { await disposable.DisposeAsync(); } catch { }
    }
    return result;
}

Можливо, ви вже розумієте, чому це відбувається, але це варто детально розібратися. Така поведінка не є специфічною для await using. Це сталося б і з простим usingблоком. Тож, поки я Dispose()тут кажу , все це стосується і цього DisposeAsync().

usingБлок просто синтаксичний цукор для try/ finallyблоку, як розділ зауваження документації говорить. Те, що ви бачите, відбувається тому, що finallyблок завжди працює, навіть після винятку. Отже, якщо виняток трапляється, а catchблоку немає , виняток ставиться на утримування до finallyзапуску блоку, а потім викидання викидається. Але якщо виняток трапиться в finally, ви ніколи не побачите старого винятку.

Ви можете побачити це на цьому прикладі:

try {
    throw new Exception("Inside try");
} finally {
    throw new Exception("Inside finally");
}

Це не має значення, Dispose()чи DisposeAsync()викликається всередині finally. Поведінка однакова.

Перша моя думка: не кидайтеся Dispose(). Але після перегляду деяких власних кодів Microsoft, я думаю, це залежить.

Погляньте, наприклад, на їх реалізацію FileStream. І синхронний Dispose()метод, і DisposeAsync()може насправді викидати винятки. Синхронний Dispose()робить ігнорувати деякі винятки навмисно, але не всі.

Але я думаю, що важливо враховувати характер вашого класу. FileStreamНаприклад, у , наприклад, Dispose()буде передано буфер до файлової системи. Це дуже важливе завдання, і ви повинні знати, якщо це не вдалося . Ви не можете просто проігнорувати це.

Однак в інших типах об'єктів, коли ви телефонуєте Dispose(), ви справді більше не використовуєте об’єкт. Дзвінок Dispose()справді просто означає «цей об’єкт для мене мертвий». Можливо, це очищає виділену пам'ять, але помилка не впливає на роботу вашої програми. У такому випадку ви можете вирішити ігнорувати виняток усередині себе Dispose().

Але в будь-якому випадку, якщо ви хочете розрізнити виняток усередині usingабо виняток, який виникла Dispose(), вам знадобиться try/ catchблокувати всередині і зовні usingблоку:

try {
    await using (var d = new D())
    {
        try
        {
            throw new ArgumentException("I'm inside using");
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message); // prints I'm inside using
        }
    }
} catch (Exception e) {
    Console.WriteLine(e.Message); // prints I'm inside dispose
}

Або ви просто не могли використовувати using. Випишіть try/ catch/ finallyблокувати себе, де ви ловите будь виключення в finally:

var d = new D();
try
{
    throw new ArgumentException("I'm inside try");
}
catch (Exception e)
{
    Console.WriteLine(e.Message); // prints I'm inside try
}
finally
{
    try
    {
        if (D != null) await D.DisposeAsync();
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message); // prints I'm inside dispose
    }
}

ефективне використання коду обробки винятків (синтаксичний цукор для спроби ... нарешті ... Dispose ()).

Якщо ваш код обробки винятків кидає Винятки, щось по-справжньому заповнено.

Що б ще не трапилося, щоб ви навіть туди потрапили, насправді вже не матер. Код обробки несправних винятків приховує всі можливі винятки, так чи інакше. Код обробки винятків повинен бути фіксованим, що має абсолютний пріоритет. Без цього ви ніколи не отримуєте достатньо налагоджувальних даних для реальної проблеми. Я бачу, що це робиться неправильно дуже часто. Це приблизно так просто, як помилитися, як обробка голих покажчиків. Тому часто є дві статті про тематичні я посилання, які можуть допомогти вам у будь-яких основних помилках дизайну:

• Класифікація винятків, до якої слід потрапити
• Загальні хороші практики, які класифікація не могла охопити

Залежно від класифікації винятків, це те, що вам потрібно зробити, якщо ваш код оброблення винятків / розпорядження видає виняток:

Для фатальних, кісткових та розгульних рішень рішення те саме.

Екзогенних винятків слід уникати навіть за серйозних витрат. Існує причина, що ми все ще використовуємо файли журналів, а не бази даних журналів для журналу винятків - Операції з БД - це лише спосіб схильності до виникнення екзогенних проблем. Журнали - це єдиний випадок, коли я навіть не заперечую, якщо ви триматимете файл File Hand Open весь час виконання.

Якщо вам вдалося перервати зв’язок, не хвилюйтеся надто про інший кінець. Поводьтеся з нею, як робить UDP: "Я надішлю інформацію, але мені байдуже, чи отримає її інша сторона". Утилізація - це очищення ресурсів на стороні клієнта / стороні, над якою ви працюєте.

Я можу спробувати повідомити їх. Але чищення матеріалів на стороні Server / FS? Тобто те , що їх тайм - аути і їх обробка винятків несе відповідальність.

Ви можете спробувати використовувати AggregateException і змінити свій код приблизно так:

class Program 
{
    static async Task Main()
    {
        try
        {
            await using (var d = new D())
            {
                throw new ArgumentException("I'm inside using");
            }
        }
        catch (AggregateException ex)
        {
            ex.Handle(inner =>
            {
                if (inner is Exception)
                {
                    Console.WriteLine(e.Message);
                }
            });
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message);
        }
    }
}

class D : IAsyncDisposable
{
    public async ValueTask DisposeAsync()
    {
        await Task.Delay(1);
        throw new Exception("I'm inside dispose");
    }
}

https://docs.microsoft.com/ru-ru/dotnet/api/system.aggregateexception?view=netframework-4.8

https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/exception-handling-task-parallel-library