هل التحقق (...) ممارسة جيدة في ترميز C ++؟

Question

أيضًا ، كيف يمكن مقارنتها برمي استثناء عندما يحدث خطأ ما؟

Answer 1

VERIFY() يخدم نفس الغرض مثل ASSERT() (أو المكتبة القياسية assert()) - للسماح لك بالقبض على الأشياء حقًا لا ينبغي على الإطلاق ™ كن يحدث (أي خطأ رمز حقيقي ، شيء يجب إصلاحه قبل الإصدار). أنواع الأشياء التي إذا كان التعبير خاطئًا لسبب ما ، فلا جدوى من الاستمرار لأن هناك شيئًا ما خاطئًا فظيعًا.

ينعكس هذا في حقيقة أن VERIFY() يوقف البرنامج فقط عن تقييم خاطئ عند التجميع في وضع التصحيح - في وضع الإصدار ، إنه شفاف. الفرق بين VERIFY() و ASSERT() هل هذا VERIFY() سيظل تقييم التعبير في وضع الإصدار ، ببساطة لن يهتم بالنتيجة - في حين ASSERT() تتم إزالتها بالكامل من البرنامج عند التجميع في وضع الإصدار ، وبالتالي لن تحدث أي آثار جانبية للتعبير داخله.

الاستثناءات أكثر فائدة للأشياء التي قد احصل على خطأ ، ولكن يمكن استردادها ، حيث يمكن التعامل مع الاستثناءات من قبل أجزاء أخرى من البرنامج.

Answer 2

يبدو السؤال بسيطًا ، لكنه يخفي موضوعًا ضخمًا: التعامل مع الأخطاء.

ملخص أود أن أقول يجزم و تحقق هي أدوات لاستخدامها في عملية التطوير في حين استثناءات ومكالمات النظام ، فحص الخطأ هي الأجزاء العادية من رمز الإنتاج للتعامل معها أخطاء وقت التشغيل.

• التأكيدات (ينطبق على التأكيد والتحقق) هي الأدوات المستخدمة في الغالب في نمط البرمجة الدفاعية. هدفهم الرئيسي هو الحماية من الحالات التي يجب ألا تحدث أبدًا وليس للمبرمج أي فكرة عما يجب فعله إذا حدث ذلك. عادة ما يتم استخدامه للتحقق من أخطاء البرمجة. عندما يحدث المستحيل أثناء تصحيح البرنامج الذي ترغب عادة في اكتشافه والإبلاغ عنه في أسرع وقت ممكن. سوف تبسيط تصحيح الخطأ. يمكنك استخدامه مع بعض الحالات أو حتى assert(false) عادة للتحقق من أن فرع المفتاح لم يتم القبض عليه أبدًا.

  أستخدم التأكيدات في الغالب عند التعامل مع رمز الطرف الثالث الذي لست متأكدًا. للتحقق من سلوك رمز الرمز الخاص بي قيد التطوير ، عادةً ما أفضّل اختبار الوحدة.

  الآن ، كما علمنا Schroëdinger ، يغير Mesures الأشياء. قد يكون لديك في وقت ما رمز يعمل في وضع التصحيح عند تمكين Assert والتوقف عن العمل في وضع الإصدار. وعادة ما يكون أعراض علة خفية داخل حالة التأكيد (التأثير الجانبي ، رمز حساس الوقت). تحقق من تقليل هذا النوع من المخاطر ، ولكن يمكن اعتباره ممارسة سيئة ، مثل الغبار الشوكي خلف السجادة.

  تستطيع ايضا استخذام تحقق للحصول على الترميز السريع باعتباره scafolding للأماكن التي لم تقم فيها بإعداد خطأ حقيقي حتى الآن. لا أعتقد أنه يجب عليك السماح لأي التحقق في رمز الإنتاج.

• استثناءات هي جزء طبيعي من تدفق التحكم في البرنامج. غالبًا ما يتم استخدامها للتعامل مع الأخطاء ، لكنها ليست استخدامها الوحيد الممكن (أولئك الذين يستخدمون لغات أخرى مثل Python سيعرفون ما أتحدث عنه). لا ينبغي اعتبارها أداة إدارة الأخطاء الوحيدة. عندما لا تكون ملفوفة في مكتبة C ++ Aware ، لا تزال مكالمات النظام تُرجع رمز الخطأ بدلاً من رفع استثناء.

  كقاعدة عامة ، يجب أن يتم القبض على استثناءات الإبهام من قبل أقرب كائن قادر على التعامل معها بشكل معقول.

  كما أنه لا ينبغي اعتبار جميع الاستثناءات أخطاء قاتلة وبرنامج إيقاف. تخيل أنك تتعامل مع مكتبة دفق الفيديو التي تعيد مكتبة إرجاع الشبكة من خلال استثناءات. إنها ترمي المكتبة تحذيرًا استثناءً من أن الإطار قد تم إسقاطه ، وعادة ما لا ترغب في إيقاف البرنامج ولكن فقط استعد للإطار التالي.

  حتى عندما يكون أفضل شيء القيام به هو إيقاف البرنامج ، يجب ألا تدع الاستثناء يفعل ذلك من أجلك (ولديك سبب أقل لاستخدام التأكيد لهذا الغرض في رمز الإنتاج). يجب أن يكون هناك دائمًا معالج استثناء من المستوى الأعلى لهذا الغرض الذي يجعل المكالمات الصريحة للخروج () من الأمراض. عدم القيام بذلك فقط يظهر أن المبرمج لم يهتم بما قد يحدث وربما لم يفكر فيه.

Answer 3

في Visual C ++ ، هناك وحدات ماكرو للتحقق من الشروط: ASSERT و VERIFY.

في وضع التصحيح ، يتصرف كلاهما على نفس المنوال: أي أن كلاهما يقيم جدالهما وإذا كانت النتيجة 0 ، فقد توقف كلاهما البرنامج مع مربع حوار فشل التأكيد.

الفرق يكمن في وضع الإصدار. في الإصدار ، الوضع ، ASSERT تمت إزالته بالكامل من البرنامج: لا يقيم تعبيره على الإطلاق. VERIFY, ، من ناحية أخرى ، لا يزال يقيم التعبير ، فهو يتجاهل النتيجة فقط.

شخصيا, رأيي هو أنه إذا كان الشيك قيمة في وضع التصحيح ، فسيظل قيمة في وضع الإصدار أيضًا وربما لا ينبغي عليك استخدام أي منهما. ما عليك سوى إجراء الاختبار ورمي استثناء (أو استخدم ماكرو مخصص يتوسع إلى assert() في وضع التصحيح واستثناء في وضع الإصدار).