متى يجب استخدام التصحيح.يؤكد()?

Question

لقد كنت مهندس البرامج المهنية لمدة عام تقريبا الآن ، بعد أن تخرج مع CS درجة.لقد عرفت عن تأكيدات لفترة من الوقت في C++ و C ، ولكن ليس لديه أي فكرة كانت موجودة في C#.صافي في كل شيء حتى في الآونة الأخيرة.

الإنتاج لدينا لا يتضمن قانون يؤكد على الإطلاق و سؤالي هو...

يجب أن تبدأ باستخدام يؤكد في الإنتاج لدينا رمز ؟ وإذا كان الأمر كذلك ، عندما يتم استخدام أكثر ملاءمة ؟ سيكون من المنطقي أكثر أن تفعل

Debug.Assert(val != null);

أو

if ( val == null )
    throw new exception();

Answer 1

في التصحيح Microsoft .NET 2.0 التطبيقات جون روبنز كبير القسم على التأكيدات.له نقاط رئيسية هي:

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

PS:إذا كنت تحب رمز كاملة, أوصي بمتابعة هذا الأمر مع هذا الكتاب.اشتريتها عن WinDBG و ملفات تفريغ, ولكن في النصف الأول هي معبأة مع نصائح للمساعدة على تجنب الأخطاء في المقام الأول.

Answer 2

وضع Debug.Assert() في كل مكان في الكود حيث تريد أن التعقل الشيكات للتأكد من الثوابت.عند ترجمة بيان بناء (أي لا DEBUG مترجم ثابت) ، يدعو إلى Debug.Assert() سيتم إزالتها حتى لا تؤثر على الأداء.

يجب أن لا تزال رمي الاستثناءات قبل الاتصال Debug.Assert().في تأكيد فقط يتأكد من أن كل شيء كما هو متوقع في حين كنت لا تزال النامية.

Answer 3

من رمز كاملة

8 دفاعية البرمجة

8.2 التأكيدات

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

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

التأكيد عادة ما يستغرق حجتين:تعبير منطقي أن يصف افتراض أن من المفترض أن يكون صحيحا و رسالة عرض إذا لم يكن.

(…)

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

Answer 4

FWIW ...أجد أن بلدي الطرق العامة تميل إلى استخدام if () { throw; } نمط للتأكد من أن طريقة يسمى بشكل صحيح.خاصة تميل إلى استخدام أساليب Debug.Assert().

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

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

Answer 5

استخدام يؤكد أن تحقق المطور الافتراضات استثناءات تحقق البيئية الافتراضات.

Answer 6

إذا كنت أنت وأود أن تفعل:

Debug.Assert(val != null);
if ( val == null )
    throw new exception();

أو لتجنب تكرار شرط الفحص

if ( val == null )
{
    Debug.Assert(false,"breakpoint if val== null");
    throw new exception();
}

Answer 7

إذا كنت تريد يؤكد في رمز الإنتاج (أينسخ الإصدار) ، يمكنك استخدام تتبع.تأكيد بدلا من التصحيح.التأكيد.

هذا بالطبع إضافة النفقات العامة على الإنتاج القابل للتنفيذ.

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

يمكنك تجاوز هذا السلوك من خلال إزالة DefaultTraceListener:نظرة على الوثائق النادرة.المستمعين في MSDN.

في الموجز ،

• استخدام التصحيح.تأكيد متحررا للمساعدة في القبض الأخطاء في التصحيح يبني.

• إذا كنت تستخدم أي أثر.يؤكدون في واجهة المستخدم الوضعية ، ربما كنت ترغب في إزالة DefaultTraceListener لتجنب القلق المستخدمين.

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

Answer 8

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

فأنا في العادة الاستثناءات أكثر ويؤكد عندما أنا لست متأكدا.

Answer 9

في الغالب لا في كتابي.في الغالبية العظمى من الحالات إذا كنت ترغب في التحقق إذا كان كل شيء هو عاقل ثم رمي إذا لم يكن.

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

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

أعتقد أن هناك ربما الأداء الحرجة سيناريوهات حيث كنت ترغب في تحسين بعيدا يؤكد أنهم فائدة هناك ، ومع ذلك أنا لم تواجه مثل هذا السيناريو.

Answer 10

باختصار

Asserts تستخدم حراس لفحص تصميم العقد القيود ، بمعنى:

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

تأكيدات لها فائدة كبيرة:

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

...مزيد من التفاصيل

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

عندما يجب عليك استخدام Asserts? - في أي نقطة في النظام ، أو مكتبة API أو الخدمة حيث المدخلات إلى وظيفة أو الدولة من فئة يفترض أنها صالحة (على سبيل المثالعند التحقق من صحة قد تم بالفعل على إدخال المستخدم في عرض الطبقة من نظام العمل والبيانات الطبقة الطبقات عادة نفترض أن null الشيكات مجموعة الشيكات طول السلسلة الشيكات وغيرها على مساهمة تم القيام به بالفعل).- المشتركة Assert الشيكات تشمل المكان غير صالح افتراض أن يؤدي إلى null object إلغاء مرجعية ، صفر المقسوم العددي أو تاريخ تجاوز الحساب العامة من الفرقة / ليست مصممة السلوك (مثلا ، إذا كان 32 بت الباحث استخدم نموذج الإنسان عمر أنه سيكون من الحكمة أن Assert أن عمر هو في الواقع بين 0 و 125 أو قيم -100 و 10^10 لا).

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

تصميم العقد (DBC) الشيكات المتوفرة تشمل:

• Contract.Requires - التعاقد مع شروط مسبقة
• Contract.Ensures - التعاقد PostConditions
• Invariant - عن افتراض حول حالة كائن في كل نقطة في بقائه.
• Contract.Assumes - تهدئة ثابتة المدقق عند دعوة غير عقد زينت الطرق مصنوع.

Answer 11

وفقا IDesign القياسية, ، يجب أن

تؤكد كل الافتراض.في المتوسط كل السطر الخامس هو تأكيد.

using System.Diagnostics;

object GetObject()
{...}

object someObject = GetObject();
Debug.Assert(someObject != null);

كما إخلاء أود أن أذكر أنني لم أجد في العملية لتنفيذ هذا IRL.ولكن هذا هو المعيار.

Answer 12

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

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

Answer 13

كل ويؤكد يجب أن تكون التعليمات البرمجية التي يمكن أن تكون محسنة إلى:

Debug.Assert(true);

لأنه التحقق من شيء أن يكون لديك بالفعل الافتراض صحيحا.E. g.:

public static void ConsumeEnumeration<T>(this IEnumerable<T> source)
{
  if(source != null)
    using(var en = source.GetEnumerator())
      RunThroughEnumerator(en);
}
public static T GetFirstAndConsume<T>(this IEnumerable<T> source)
{
  if(source == null)
    throw new ArgumentNullException("source");
  using(var en = source.GetEnumerator())
  {
    if(!en.MoveNext())
      throw new InvalidOperationException("Empty sequence");
    T ret = en.Current;
    RunThroughEnumerator(en);
    return ret;
  }
}
private static void RunThroughEnumerator<T>(IEnumerator<T> en)
{
  Debug.Assert(en != null);
  while(en.MoveNext());
}

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

في الحالة الأولى هناك أي مشكلة.

في الحالة الثانية هناك مشكلة مع رمز الدعوة - لا يجب أن يسمى GetFirstAndConsume مع null, حتى يحصل على استثناء الظهر.

في الحالة الثالثة ، هناك مشكلة مع هذا القانون ، لأنه يجب أن يكون لديك بالفعل تم التحقق من ذلك en != null قبل كان يسمى ، حتى أن هذا ليس صحيحا هو علة.أو بعبارة أخرى ، يجب أن تكون التعليمات البرمجية التي يمكن نظريا أن تكون محسنة إلى Debug.Assert(true), sicne en != null ينبغي أن يكون دائما true!

Answer 14

فكرت في إضافة أكثر من أربع حالات ، حيث التصحيح.تأكيد يمكن أن يكون الخيار الصحيح.

1) شيء أنا لم أر ذكره هنا هو إضافية المفاهيمي التغطية يؤكد يمكن أن توفر خلال الاختبار الآلي.كمثال بسيط:

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

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

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

2) بالإضافة إلى ذلك ، بعض الاختبارات البسيطة في الكتابة ، ولكن التكلفة العالية وغير ضرورية في ضوء الافتراضات الأولية.على سبيل المثال:

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

3) المقبل, في بعض الحالات الخاصة بك المنتج قد لا يكون من المفيد تشخيص التفاعل لكل أو جزء من عملياته عند نشرها في وضع الإصدار.على سبيل المثال:

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

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

إذا الأساسية String.Find العملية الأمريكية فإنه سيعود -1 عندما تكون معايير البحث لم يتم العثور على, كنت قد تكون قادرة على القيام بأمان عملية واحدة بدلا من ثلاث.ومع ذلك ، إذا كان فعلا عاد -2, هل معقول مسار العمل.سيكون من المفيد استبدال أبسط حساب مع أحد هذه الاختبارات بشكل منفصل -1 قيمة غير معقول في معظم الإفراج عن البيئات القمامة التعليمات البرمجية الخاصة بك مع اختبارات ضمان الأساسية المكتبات تعمل كما هو متوقع.في هذه الحالة يؤكد مثالية.

Answer 15

اقتباس مأخوذ من عملي مبرمج:من مياوم لإتقان

ترك تأكيدات تشغيل

هناك سوء فهم مشترك حول التأكيدات الصادرة الناس الذين يكتبون المجمعين و اللغة البيئات.فإنه يذهب شيء من هذا القبيل:

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

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

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

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

حتى إذا كان لديك مشكلات في الأداء ، إيقاف فقط تلك مؤكدا أن ضرب حقا لك.

Answer 16

يجب عليك دائما استخدام النهج الثاني (رمي الاستثناءات).

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

Answer 17

يجب عليك استخدام التصحيح.تأكيد لاختبار الأخطاء المنطقية في البرامج الخاصة بك.مترجم فقط أبلغكم من أخطاء في بناء الجملة.لذلك يجب أن definetely استخدام تأكيد البيانات لاختبار الأخطاء المنطقية.مثل القول اختبار البرنامج الذي تبيع سيارات فقط سيارات Bmw التي الأزرق يجب أن تحصل على خصم 15%.مترجم يمكن أن أقول لكم شيئا عن إذا كان البرنامج الخاص بك هو الصحيح منطقيا في أداء هذا ولكن تأكيد البيان يمكن.

Answer 18

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

في الحالة الأولى ، التأكيدات حتى لا تحتاج إلى أن تكون في النهائي رمز.يجب عليك استخدام Debug.Assert خلال والتنمية يمكنك إزالتها إذا/عندما لم تعد هناك حاجة.إذا كنت تريد أن تترك لهم أو إذا كنت قد نسيت أن إزالتها لا مشكلة لأنها لن يكون لها أي نتيجة في الإفراج عن مصنفات.

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

Trace.Assert وقد الطريقة المثلى لتحقيق ذلك.فإنه لا يمكن إزالتها في الإنتاج و يمكن تكوين مع مختلف المستمعين باستخدام التطبيق.config.لذلك من أجل التنمية الافتراضي معالج جيد و إنتاج يمكنك إنشاء بسيط TraceListener مثل أدناه الذي يطرح استثناء وتفعيل ذلك في إنتاج ملف التكوين.

using System.Diagnostics;

public class ExceptionTraceListener : DefaultTraceListener
{
    [DebuggerStepThrough]
    public override void Fail(string message, string detailMessage)
    {
        throw new AssertException(message);
    }
}

public class AssertException : Exception
{
    public AssertException(string message) : base(message) { }
}

و في إنتاج config:

<system.diagnostics>
  <trace>
    <listeners>
      <remove name="Default"/>
      <add name="ExceptionListener" type="Namespace.ExceptionTraceListener,AssemblyName"/>
    </listeners>
  </trace>
 </system.diagnostics>

Answer 19

أنا لا أعرف كيف هو في C#.صافي ، ولكن في C تأكيد() تعمل فقط إذا جمعت مع DDEBUG - على enduser لن ترى رسالة تأكيد() إذا كان جمعت دون.يفعل المطور فقط.أنا استخدامها في كثير من الأحيان حقا, انها في بعض الأحيان من الأسهل لتتبع الأخطاء.

Answer 20

وأود أن لا استخدامها في إنتاج التعليمات البرمجية.رمي الاستثناءات التقاط وتسجيل.

تحتاج أيضا إلى توخي الحذر في asp.net ، كما تؤكد يمكن أن تظهر على وحدة تجميد الطلب(s).