Właściwy sposób radzenia sobie z wyjątkami w AsyncDispose

Podczas przechodzenia na nową platformę .NET Core 3 IAsynsDisposablenatknąłem się na następujący problem.

Rdzeń problemu: jeśli DisposeAsynczgłasza wyjątek, wyjątek ten ukrywa wszelkie wyjątki await usingzgłoszone w bloku.

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

Tym, co zostaje złapane, jest AsyncDisposewyjątek, jeśli zostanie rzucony, a wyjątek od wewnątrz await usingtylko, jeśli AsyncDisposenie zostanie rzucony .

Wolałbym jednak odwrotnie: uzyskać wyjątek od await usingbloku, jeśli to możliwe, i- DisposeAsyncwyjątek tylko wtedy, gdy await usingblok zakończy się pomyślnie.

Uzasadnienie: Wyobraź sobie, że moja klasa Dwspółpracuje z niektórymi zasobami sieciowymi i subskrybuje niektóre powiadomienia zdalnie. Kod w środku await usingmoże zrobić coś złego i zawieść kanał komunikacyjny, po czym kod w Dispose, który próbuje z wdziękiem zamknąć komunikację (np. Wypisać się z powiadomień), również się nie powiedzie. Ale pierwszy wyjątek daje mi prawdziwe informacje o problemie, a drugi to tylko problem wtórny.

W innym przypadku, gdy główna część przebiegła, a usuwanie nie powiodło się, prawdziwy problem jest w środku DisposeAsync, więc wyjątek od DisposeAsyncjest odpowiedni. Oznacza to, że zniesienie wszystkich wyjątków w środku DisposeAsyncnie powinno być dobrym pomysłem.

Wiem, że ten sam problem występuje w przypadku niesynchronicznym: wyjątek w finallyzastępuje wyjątek w try, dlatego nie zaleca się wrzucania Dispose(). Jednak w przypadku klas korzystających z dostępu do sieci tłumienie wyjątków w metodach zamykania wcale nie wygląda dobrze.

Możliwe jest obejście problemu za pomocą następującego pomocnika:

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 { }
        }
    }
}

i używaj go jak

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

co jest trochę brzydkie (i uniemożliwia takie rzeczy, jak wczesne powroty do bloku używającego).

Czy istnieje dobre kanoniczne rozwiązanie, await usingjeśli to możliwe? Moje wyszukiwanie w Internecie nie znalazło nawet dyskusji na ten temat.

Są wyjątki, które chcesz ujawnić (przerwać bieżące żądanie lub sprowadzić proces), i są wyjątki, których oczekiwanie może się zdarzyć, i możesz sobie z nimi poradzić (np. Spróbuj ponownie i kontynuuj).

Ale rozróżnienie tych dwóch typów zależy od ostatecznego wywołującego kodu - jest to cały wyjątek, aby decyzja pozostawić osobie wywołującej.

Czasami program wywołujący przywiązuje większą wagę do ujawnienia wyjątku z oryginalnego bloku kodu, a czasem wyjątku od Dispose. Nie ma ogólnej zasady decydowania o tym, które powinny mieć pierwszeństwo. CLR jest co najmniej spójny (jak zauważyłeś) między zachowaniem synchronizacji a niesynchronizacją.

Być może niefortunne jest to, że teraz musimy AggregateExceptionreprezentować wiele wyjątków, więc nie można tego doposażyć do rozwiązania tego problemu. tzn. jeśli wyjątek jest już w locie, a inny zostanie zgłoszony, są one łączone w AggregateException. catchMechanizm może zostać zmodyfikowany tak, że jeśli piszesz catch (MyException)to będzie złapać każdy AggregateException, który zawiera wyjątek typu MyException. Istnieje jednak wiele innych komplikacji wynikających z tego pomysłu i prawdopodobnie modyfikowanie czegoś tak fundamentalnego jest prawdopodobnie zbyt ryzykowne.

Możesz ulepszyć swój system, UsingAsyncaby wspierać wczesny zwrot wartości:

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

Być może już rozumiesz, dlaczego tak się dzieje, ale warto to wyjaśnić. To zachowanie nie jest specyficzne dla await using. To by się stało z prostym usingblokiem. Tak więc, kiedy mówię Dispose()tutaj, wszystko to dotyczy DisposeAsync()również.

usingBlok jest po prostu cukier syntaktyczny dla try/ finallybloku, jak sekcja Uwagi dokumentacji mówi. To, co widzisz, dzieje się, ponieważ finallyblok zawsze działa, nawet po wyjątku. Jeśli więc zdarzy się wyjątek i nie będzie catchbloku, wyjątek zostanie wstrzymany do momentu uruchomienia finallybloku, a następnie wyjątek zostanie zgłoszony . Ale jeśli zdarzy się wyjątek finally, nigdy nie zobaczysz starego wyjątku.

Możesz to zobaczyć na tym przykładzie:

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

Nie ma znaczenia, czy Dispose()czy DisposeAsync()nazywa się wewnątrz finally. Zachowanie jest takie samo.

Moja pierwsza myśl to: nie wrzucaj Dispose(). Ale po przejrzeniu części własnego kodu Microsoftu, myślę, że to zależy.

Spójrz na FileStreamprzykład na ich wdrożenie . Zarówno Dispose()metoda synchroniczna , jak i DisposeAsync()może generować wyjątki. Synchroniczna Dispose()nie ignorować pewne wyjątki celowo, ale nie wszystkie.

Ale myślę, że ważne jest, aby wziąć pod uwagę charakter swojej klasy. Na FileStreamprzykład, Dispose()opróżni bufor do systemu plików. To bardzo ważne zadanie i musisz wiedzieć, czy to się nie powiodło . Nie możesz tego po prostu zignorować.

Jednak w innych typach obiektów, kiedy wywołujesz Dispose(), naprawdę nie ma już dla niego żadnego pożytku. Wywołanie Dispose()naprawdę oznacza po prostu „ten obiekt jest dla mnie martwy”. Może to czyści część przydzielonej pamięci, ale niepowodzenie nie wpływa w żaden sposób na działanie aplikacji. W takim przypadku możesz zignorować wyjątek w swoim pliku Dispose().

Ale w każdym razie, jeśli chcesz rozróżnić wyjątek wewnątrz usinglub wyjątek, który przyszedł Dispose(), potrzebujesz try/ catchbloku zarówno wewnątrz, jak i na zewnątrz usingbloku:

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
}

Lub po prostu nie możesz użyć using. Wypisać try/ catch/ finallyblokować siebie, gdzie można złapać żadnego wyjątku w 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
    }
}

efektywne korzystanie z kodu obsługi wyjątków (cukier składniowy dla try ... wreszcie ... Dispose ()).

Jeśli kod obsługi wyjątków zgłasza wyjątki, coś po królewsku zostaje zepsute.

Cokolwiek jeszcze się zdarzyło, żeby cię tam dostać, tak naprawdę nie ma już znaczenia. Wadliwy kod obsługi wyjątków ukryje wszystkie możliwe wyjątki, w ten czy inny sposób. Kod obsługi wyjątków musi zostać naprawiony, co ma absolutny priorytet. Bez tego nigdy nie uzyskasz wystarczającej ilości danych do debugowania dla prawdziwego problemu. Widzę, że robi się to wyjątkowo źle. Łatwo się pomylić, tak samo jak posługiwanie się nagimi wskazówkami. Tak często istnieją dwa artykuły na temat I link, które mogą pomóc w wszelkich podstawowych nieporozumień projektowych:

• Klasyfikacja wyjątków i które powinieneś złapać
• Ogólne dobre praktyki, których klasyfikacja nie mogła obejmować

W zależności od klasyfikacji wyjątków, musisz to zrobić, jeśli Twój kod obsługi wyjątku / upuszczenia zgłasza wyjątek:

W przypadku Fatal, Boneheaded i Vexing rozwiązanie jest takie samo.

Egzogenicznych wyjątków należy unikać nawet przy poważnych kosztach. Jest powód, dla którego nadal używamy plików dziennika , a nie baz danych do rejestrowania wyjątków - DB Opeartions to po prostu sposób na skłonność do wpadania w problemy egzogeniczne. Pliki dziennika to jedyny przypadek, w którym nawet nie mam nic przeciwko, jeśli zachowasz uchwyt pliku Otwórz cały środowisko wykonawcze.

Jeśli musisz zamknąć połączenie, nie przejmuj się zbytnio drugim końcem. Postępuj tak, jak robi to UDP: „Wyślę informacje, ale nie dbam o to, czy dostanie je druga strona”. Pozbywanie się polega na czyszczeniu zasobów po stronie klienta / stronie, nad którą pracujesz.

Mogę spróbować ich powiadomić. Ale sprzątanie rzeczy po stronie serwera / FS? To, co ich limity czasu i ich obsługa wyjątków jest odpowiedzialny.

Możesz spróbować użyć AggregateException i zmodyfikować kod w taki sposób:

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