يقترح ReSharper و (في السنوات الأخيرة) Visual Studio إدراج ArgumentNullException وفحوصات وسيطة مماثلة. إنها ذاكرة عضلية أدخلتها بالصدفة إلى قاعدة الرموز عدة مرات.
يعتبر الرمي المباشر أكثر اصطلاحات C # من وجهة نظر تحليل التحكم في التدفق. يتفهم المحول البرمجي C # أنك لست بحاجة إلى إرجاع قيمة أو تهيئة متغير قبل الاستخدام أو الانقطاع عن حالة التبديل إذا كنت تستخدم throw
بدلاً من Guard
. فحص التدفق الفارغ لـ ReSharper هو بنفس الطريقة.
أيضًا ، مع C # 7.0 ، يمكن أن تكون تعبيرات الرمي مريحة. على سبيل المثال ، بناء الجملة _foo = foo ?? throw new ArgumentNullException(nameof(Foo));
.
ما هي إيجابيات وسلبيات السماح للمساهمين وأنفسنا برمي الاستثناءات مباشرةً بدلاً من استخدام Guard؟
المحترف الرئيسي لاستخدام فئة Guard
هو سهولة الاستخدام ، إذا كنت أتذكر بشكل صحيح. في C # -aware IDE ، لم يعد الخيار الأسهل بالنسبة لي أو للمساهمين الجدد. هل نحن بحاجة إلى الاتساق ، بطريقة أو بأخرى؟ التناسق يضع ما هو أسهل بالنسبة للبعض منا ضد (من المحتمل) ما هو الأسهل بالنسبة للآخرين منا.
أنا شخصياً أحب فصل الحارس - لكني أوافق على وجود مشكلة اكتشاف. عادةً ما أقترحه على المساهمين المنتظمين ، لكن لا أذكره للمساهمين الفرديين. لا أعتقد أن هذا مجال نحتاجه بشكل خاص إلى الاتساق ، أليس كذلك؟ يسعدني رؤيته عندما يكون هناك ، لكنني لست قلقًا عندما لا يكون كذلك.
أنا غير مبالي إلى حد ما بنتيجة هذه القضية ، في كلتا الحالتين جيد بالنسبة لي
أنا أيضا غير مبالي إلى حد ما حيال ذلك. إنه يوفر الاتساق والاستخدام الصحيح لمنشئي الاستثناءات (لقد رأيت الرسالة واسم المعلمة يتراجعان عدة مرات) ، ولكنه يضيف أيضًا طريقة إضافية إلى callstack. بالإضافة إلى ذلك ، كما قلت ، فإن بناء جملة C # الجديد يجعل الأمر أسهل بكثير.
لست متأكدًا من أننا بحاجة إلى تطهير بالجملة ، لكنني لا أمانع عدم طلب ذلك.
شكرا للجميع ، يبدو جيدا!
التعليق الأكثر فائدة
أنا شخصياً أحب فصل الحارس - لكني أوافق على وجود مشكلة اكتشاف. عادةً ما أقترحه على المساهمين المنتظمين ، لكن لا أذكره للمساهمين الفرديين. لا أعتقد أن هذا مجال نحتاجه بشكل خاص إلى الاتساق ، أليس كذلك؟ يسعدني رؤيته عندما يكون هناك ، لكنني لست قلقًا عندما لا يكون كذلك.
أنا غير مبالي إلى حد ما بنتيجة هذه القضية ، في كلتا الحالتين جيد بالنسبة لي