يرمي إلى العودة أو errno?

Question

أنا خلق نظام.ما أريد معرفته هو إذا msg غير معتمد ماذا يجب أن تفعل ؟ يجب رمي قول غير معتمد msg ؟ يجب أن أعود 0 أو -1?أو يجب تعيين errno (قاعدة->errno_).بعض الرسائل أنا لا يهمني إذا كان هناك خطأ (مثل setBorderColour).الآخرين أود أن (addText أو ربما حفظ إذا كنت إنشاء حفظ cmd).

أريد أن أعرف ما هي أفضل طريقة هي: 1) الترميز بسرعة 2) التصحيح 3) توسيع و صيانة.قد جعل التصحيح 3rd, من الصعب تصحيح الصراف الآلي ولكن هذا قبل الميلاد وهناك الكثير من المفقودين رمز التي لم تملأ.الفعلية البق تخلخل من الصعب الصحيح.ما أفضل طريقة السماح للمستخدم يعرفون أن هناك خطأ ؟

النظام يعمل شيء مثل هذا ولكن ليس بالضبط نفس الشيء.هذا هو C أسلوب mycode يحتوي على مجموعة من وظائف مضمنة أن التفاف settext(const char*النص){ إلى msg(هذا esettext ، النص)

Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);

Answer 1

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

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

في محاولة لتجنب أي وقت مضى باستخدام errno ، لأنه هو عرضة للخطأ نفسه.إنه عالمي, لذلك أنت لا تعرف من هو إعادة عليه, و هو الأكثر نهائيا لا موضوع آمنة.

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

Answer 2

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

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

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

Answer 3

وشخصيا عندما يتعلق الأمر الرسومات الإخراج، أشعر صامتة تفشل على ما يرام. فإنه يجعل من مجرد صورتك الخطأ.

والأخطاء الرسومية سهلة فائقة على الفور على أي حال.

Answer 4

وشخصيا، وأود أن أضيف إلى errno إلى بنية قاعدة الخاص بك إذا كان هو محض "C". إذا كان هذا هو C ++ فما استقاموا لكم فاستقيموا رمي استثناء.

وهذا يعتمد على كيف 'قاتلة' هي هذه الأخطاء. هل المستخدم حقا بحاجة الى ان نرى الخطأ، أم أنها لمطورين آخرين التنوير؟

لالصيانة تحتاج إلى توثيق بوضوح الأخطاء التي يمكن أن تحدث وتشمل أمثلة واضحة لمعالجة الأخطاء.