วิธีที่เหมาะสมในการจัดการกับข้อยกเว้นใน AsyncDispose

ระหว่างเปลี่ยนเป็น. NET Core 3 IAsynsDisposableใหม่ฉันได้พบกับปัญหาต่อไปนี้

แกนหลักของปัญหา: ถ้าDisposeAsyncมีข้อยกเว้นข้อยกเว้นนี้ซ่อนข้อยกเว้นใด ๆ ที่ถูกโยนลงในawait using-block

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สามารถทำอะไรผิดพลาดและทำให้ช่องทางการสื่อสารล้มเหลวหลังจากนั้นรหัสในการกำจัดซึ่งพยายามปิดการสื่อสารอย่างนุ่มนวล (เช่นการยกเลิกการสมัครรับการแจ้งเตือน) ก็จะล้มเหลวเช่นกัน แต่ข้อยกเว้นแรกให้ข้อมูลจริงเกี่ยวกับปัญหาและข้อที่สองเป็นเพียงปัญหารอง

ในอีกกรณีหนึ่งเมื่อส่วนหลักวิ่งผ่านและการกำจัดล้มเหลวปัญหาที่แท้จริงคือภายในDisposeAsyncดังนั้นข้อยกเว้นจากDisposeAsyncเป็นส่วนที่เกี่ยวข้อง ซึ่งหมายความว่าเพียงระงับการยกเว้นทั้งหมดภายในDisposeAsyncไม่ควรเป็นความคิดที่ดี

ฉันรู้ว่ามีปัญหาเดียวกันกับกรณีที่ไม่ใช่ async: ข้อยกเว้นใน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หรือคุณอาจจะไม่ใช้ เขียน a try/ catch/ finallyblock ด้วยตัวคุณเองซึ่งคุณจะได้รับข้อยกเว้นใน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
    }
}

ใช้อย่างมีประสิทธิภาพยกเว้นรหัสการจัดการ (ไวยากรณ์น้ำตาลสำหรับลอง ... ในที่สุด ... ทิ้ง ()

หากรหัสการจัดการข้อยกเว้นของคุณกำลังขว้างข้อยกเว้นบางอย่างจะถูกเก็บไว้อย่างมากมาย

อะไรก็ตามที่เกิดขึ้นกับคุณแม้กระทั่งนำคุณไปที่นั่นไม่ได้เป็นแม่อีกต่อไป รหัสการจัดการข้อผิดพลาดจะซ่อนข้อยกเว้นที่เป็นไปได้ทั้งหมดไม่ทางใดก็ทางหนึ่ง รหัสการจัดการข้อยกเว้นต้องได้รับการแก้ไขซึ่งมีความสำคัญสูงสุด หากปราศจากสิ่งนั้นคุณจะไม่ได้รับข้อมูลการดีบักเพียงพอสำหรับปัญหาจริง ฉันเห็นว่ามันทำผิดอย่างมากบ่อยครั้ง มันเป็นเรื่องง่ายที่จะเข้าใจผิดว่าจัดการตัวชี้เปล่า บ่อยครั้งที่มีบทความสองบทความเกี่ยวกับหัวข้อที่ฉันเชื่อมโยงซึ่งอาจช่วยให้คุณเข้าใจถึงความเข้าใจผิดเกี่ยวกับการออกแบบ:

• การจำแนกประเภทของข้อยกเว้นและสิ่งที่คุณควรจับ
• แนวปฏิบัติที่ดีทั่วไปที่การจำแนกประเภทไม่สามารถครอบคลุมได้

นี่คือสิ่งที่คุณต้องทำหากการจัดการข้อยกเว้น / รหัส Dipose ของคุณขึ้นอยู่กับการจำแนกประเภทข้อยกเว้น

สำหรับ Fatal, Boneheaded และ Vexing วิธีการแก้ไขก็เหมือนกัน

ข้อยกเว้นภายนอกจะต้องหลีกเลี่ยงแม้จะมีค่าใช้จ่ายสูง มีเหตุผลที่เรายังคงใช้ล็อกไฟล์แทนจากนั้นล็อกฐานข้อมูลเพื่อบันทึกข้อยกเว้น - DB Opeartions เป็นวิธีที่จะทำให้เกิดปัญหาจากภายนอกได้ง่าย Logfiles เป็นกรณีหนึ่งที่ฉันไม่สนใจถ้าคุณเก็บ File Handle เปิด Runtime ทั้งหมด

หากคุณต้องปิดการเชื่อมต่อไม่ต้องกังวลกับส่วนอื่น ๆ จัดการได้เหมือนกับที่ UDP ทำ: "ฉันจะส่งข้อมูล แต่ฉันไม่สนใจว่าอีกฝ่ายรับข้อมูลมาหรือไม่" การกำจัดคือการล้างทรัพยากรในฝั่งไคลเอ็นต์ / ฝั่งที่คุณกำลังทำงาน

ฉันสามารถลองแจ้งเตือนได้ แต่การล้างข้อมูลในฝั่งเซิร์ฟเวอร์ / 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