سؤال

تصفح الشبكة لتحسين التعامل مع الأخطاء في C#، لقد كوم عبر ما يلي إلى استراتيجيات التنفيذ. أول واحد طبيعي بالنسبة لي ، في حين أن التنفيذ الآخر لست متأكدًا من مزاياه؟

1)

static void Fault(Action protectedBlock, Action faultHandler)
{ 
    try
    {
        protectedBlock();
    }
    catch
    {
        faultHandler();
        throw;
    }
}

2)

static Action Fault(Action protectedBlock, Action faultHandler)
{
    return () =>
    {
        try
        {
            protectedBlock();
        }
        catch
        {
            faultHandler();
            throw;
        }
    };
}

هل 2) الاستراتيجية المفضلة عند تطوير وظائف ترتيب أعلى في C#؟

وأنا أتساءل ، إذا كان أحد النهج أكثر كفاءة من الآخر.

هل كانت مفيدة؟

المحلول

الحالة الثانية تشبه مصنع العمل القابل للخطأ. حيث تمر في مندوب ما تريد القيام به ، protectedBlock, ومندوب ما يجب فعله عندما يكون Exception يحدث، faultHandler. يتم إرجاع الإجراءات ملفوفة في بنية المحاولة/الصيد كجميع Action. مشكلتي في كلتا الطريقتين لا Exception في الواقع يتم القبض عليه ، لذا فإن من الذي سيقوم بالقبض على رميتك ليس لديه معلومات عن التصرف عنها.

الفرق في التنفيذ بين 2 هو عندما يتم تنفيذها بالفعل. سيتم تنفيذ الأول عندما يطلق عليه. سيتم تنفيذ الثانية كلما تم إرجاعها Action يسمى. لا أعتقد أن فرق الكفاءة سيكون كبيرًا.

نصائح أخرى

(2) يمكن أن يتكون أكثر ، بينما (1) يعمل فقط. لكن ليسا "وظيفيين" بالضبط مثل Action ليست وظيفة (قارن مع Func<A, R>).

لذلك مع (2) يمكنك أن تفعل:

Fault(someAction, Fault(firstTryFaultHandler, lastDitchFaultHandler))();

... والحصول على السلوك المتوقع. هذا لا يعمل مع (1)

في C#، يمكن أن يكون النهج 2 مربكًا. قد يستخدم المتصل "خطأ (أ ، ب) ؛" توقع A وربما B ليتم استدعاؤه. بدلاً من ذلك ، يتم إنشاء Lambda وإعادته وتجاهله. وبعبارة أخرى ، لا يوجد شيء.

فيما يتعلق بالكفاءة ، فإن النهج 2 مضيعة بعض الشيء إذا كانت معظم مكالماتك من النموذج "خطأ (أ ، ب) () ؛" ، أي أنك تستدعي لامدا على الفور. في هذه الحالة ، لا تحتاج إلى Lambda.

لهذه الأسباب ، أفضل النهج 1. إذا كنت بحاجة إلى تأجيل التنفيذ ، فيمكنك تقديم Lambda بشكل صريح "() => خطأ (A ، B)".

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top