طريقة لمعرفة الوظائف التي يمكن أن تعيد الاستثناء تلقائيا في C #

Question

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

هل هناك طريقة سهلة للمسح من خلال مصادرك وعلامة كل الوظائف التي يمكن أن ترمي استثناءات؟

هل يوجد بناء في المساعدة المرئية بعض الخيار المخفي لتلوين هذه الوظائف بلون معين؟

شكرا

رديئة

Answer 1

أعتقد أن Redgate لديه بعض الأداة لهذا "صياد الاستثناء" الذي يفرضون عليه بعد تجربة.

http://www.red-gate.com/products/exception_hunter/index.htm.

Answer 2

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

Answer 3

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

1. النظر في استثناءات إلقاؤها ضمنيا مثل StackoverFlowException يمكن إلقاءها في أي وقت من أي طريقة. يجب أن تفترض أن أي طريقة في CLR يمكن أن ترمي هذه الأنواع من الاستثناءات
2. يمكن أن يؤدي الانعكاس و / أو المندوبين إخفاء الرمز الفعلي الذي يتم استدعاؤه بطريقة معينة حتى لا تتمكن من فحص جميع مسارات التعليمات البرمجية المحتملة من الطريقة.
3. هذا سيتطلب تفتيش IL مقابل البيانات الوصفية.
4. في .NET لا يوجد شرط لإجراءات المستندات التي يتم إلقاؤها صراحة من قبل API

Answer 4

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

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

Answer 5

أعتقد أن التجديد يمنحك تلميحات في الاستثناءات. ولكن بسبب السبب في أن C # لا يدعم الاستثناءات المحددة، هناك طريقة لتحديد الاستثناءات. اسم أدوات تحليل الكود مثل ndepend دعم هذا.

Answer 6

كل شيء يمكن أن يرمي استثناء. تحقق MSDN للحصول على قائمة بالاستثناءات التي يمكن إلقاؤها بواسطة طريقة.

Answer 7

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

/// <summary>  
/// I seem to have written a method to do a thing.
/// </summary>  
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
   /* ... */
}

Answer 8

أي رمز يمكن أن يسبب استثناء هو عملك في محاولة وتوقع ذلك!

هناك عدد من أدوات الطرف الثالث التي قد تساعد في العثور على بعض الأخطاء الشائعة مثل FXCOP والأدوات مثل Refactor يمكن أن تقدم اقتراحات.

هناك بعض الأعمال التي تم القيام بها في الوقت الحالي يمكن أن تساعدك في العثور على استثناءات محتملة. إلقاء نظرة على PEX التي يمكن أن تساعد في توليد اختبارات لوظائفك: البحث.microsoft.com/en-projects/projects/pex/ (LINK يبدو أن يكون في وقت النشر)

منطقة أخرى مثيرة هي عقود التعليمات البرمجية (قادم في .NET 4 / متوفر كمواصفات #). تتيح لك عقود الكود أن تكتب البيانات التي تحدد الشروط التي يجب الوفاء بها. يمكن أن تكون هذه قبل وبعد وظيفتك التي يتم استدعاؤها ويمكنك أيضا الإعلان عن الثبات. حالة قد تكون بسيطة مثل القيمة! = null. ثم يتم تحليل هذه الشروط في الترجمة والوقت للتحقق من أي مسارات قانون تنتهكها.

Answer 9

كما قال الآخرون، يجب أن تفترض أن كل سطر رمز يمكن أن يرمي استثناء، ما لم يثبت أنه لا يمكنه ذلك. السؤال الأفضل هو، "ماذا تخطط للقيام بذلك؟"

بشكل عام، يجب ألا تقف أي استثناءات على الإطلاق.

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

public int GetConfiguredInteger(string name) {
    string s = null;
    try {
        s = GetStringFromConfigFile(name);
    }
    catch (IOException ex) {
        throw new Exception(String.Format(
            "Error in configuration file foo.config when processing {0}", name),
            ex);
    }
    return int.Parse(s);
}

لم يكن من المفترض أن يعرف المتصل أن IoException ناتج عن ملف التكوين إذا لم تخبرهم. لاحظ أيضا كيف تجاهلت جميع الاستثناءات غير المرتبطة بالملف I / O. على وجه الخصوص، لاحظ أن int.parse ليس حتى داخل كتلة المحاولة / الصيد.

هناك عدد صغير من الاستثناءات الأخرى هذه، لكن الفكرة الأساسية لافتتاح الاستثناءات هي: لا تفعل ذلك ما لم يكن الأمر سوءا إذا لم تفعل ذلك.

Answer 10

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

Answer 11

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

Answer 12

استثناء صياد المذكورة من قبل عدد قليل من الناس هو أداة جيدة للمساعدة في هذا. أنا لا أعرف ما إذا كان لديه التعادل مع <exception> التعليق XML-DOC حتى تتمكن من فرض توثيق الاستثناءات التي ألقيتها الرمز.

Answer 13

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

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

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