تجنب رسائل استثناء الفرصة الأولى عندما تتم معالجة الاستثناء بأمان

Question

الجزء التالي من التعليمات البرمجية يلتقط استثناء EOS

using (var reader = new BinaryReader(httpRequestBodyStream)) {

    try {
        while (true) {
            bodyByteList.Add(reader.ReadByte());
        }
    } catch (EndOfStreamException) { }
}

فلماذا لا أزال أتلقى استثناءات الفرصة الأولى في وحدة التحكم الخاصة بي؟

حدث استثناء الفرصة الأولى من النوع "System.IO.EndOfStreamException" في mscorlib.dll

هل هناك طريقة لإخفاء رسائل استثناء الفرصة الأولى هذه؟

Answer 1

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

ليس هناك ما يدعو للقلق.هذا هو السلوك الطبيعي.

Answer 2

لتجنب رؤية الرسائل، انقر بزر الماوس الأيمن على نافذة الإخراج وقم بإلغاء تحديد "رسائل الاستثناء".

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

Answer 3

1) في Visual Studio، يمكنك تغيير الإعدادات الخاصة بالطريقة التي يعالج بها مصحح الأخطاء (الاستثناءات).

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

هناك يتم تقديم مربع حوار للاستثناءات ومتى يتم كسرها.

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

2) يجب ألا تكون الرسالة التي تتلقاها في وحدة التحكم، ولكن يجب أن تظهر في نافذة "الإخراج" في Visual Studio.إذا كان الأمر الأخير، فلم أجد إمكانية لإزالة ذلك، ولكن لا يظهر إذا قمت بتشغيل التطبيق بدون Visual Studio.

امل ان يساعد.

Answer 4

على عكس Java، تعد استثناءات .NET باهظة الثمن إلى حد ما من حيث قوة المعالجة، ويجب تجنب الاستثناءات التي تتم معالجتها في مسار التنفيذ العادي والناجح.

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

في هذا المثال سوف تستخدم

while (reader.PeekChar() != -1)
{
    bodyByteList.Add(reader.ReadByte());
}

Answer 5

لقد واجهت هذه المشكلة ولم أتمكن من معرفة مكان طرح الاستثناء.لذلك كان الحل هو تمكين Visual Studio من التوقف عن التنفيذ على هذا النوع من الاستثناءات.

1. انتقل إلى "التصحيح/الاستثناءات"
2. قم بتوسيع شجرة "استثناءات وقت تشغيل اللغة العامة".
3. قم بتوسيع فرع "النظام".
4. قم بالتمرير لأسفل إلى مكان "NullReferenceException" ، وتحقق من مربع الاختيار "رمي" ، وإلغاء تحديد "معالجة المستخدم".
5. تصحيح مشروعك.

Answer 6

إذا كنت تريد المزيد من التحكم في هذه الرسائل، يمكنك إضافة معالج:

Friend Sub AddTheHandler()
AddHandler AppDomain.CurrentDomain.FirstChanceException, AddressOf FirstChanceExceptionHandler
End Sub

<Conditional("DEBUG")>
Friend Sub FirstChanceExceptionHandler( source As Object,  e As Runtime.ExceptionServices.FirstChanceExceptionEventArgs)
' Process first chance exception

End Sub

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

Answer 7

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

Answer 8

في VB.NET:

<DebuggerHidden()> _
Public Function Write(ByVal Text As String) As Boolean
   ...

Answer 9

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

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