بداية كتب البرمجة عادة ما تتضمن هذا التحذير: "لا تقسم على الصفر! سوف تحصل على خطأ وقت التشغيل! "
الأمور تغيرت في VB.NET. على الرغم من أن هناك أكثر من ذلك برمجة الخيارات والحساب أكثر دقة ، ليس من السهل دائمًا معرفة سبب حدوث الأشياء بالطريقة التي تحدث بها.
هنا ، نتعلم كيفية التعامل مع القسمة على الصفر باستخدام معالجة الأخطاء الهيكلية لـ VB.NET. وعلى طول الطريق ، نغطي أيضًا ثوابت VB.NET الجديدة: NaN و Infinity و Epsilon.
ماذا يحدث إذا قمت بتشغيل 'Divide By Zero' في VB.NET
إذا قمت بتشغيل سيناريو "divide by zero" في VB.NET ، فستحصل على هذه النتيجة:
خافت أ ، ب ، ج كما مزدوجة
أ = 1: ب = 0
ج = أ / ب
وحدة التحكم. WriteLine (_
"قواعد الرياضيات"
& vbCrLf & _
"ألغيت؟" _
& vbCrLf & _
"القسمة على صفر " _
& vbCrLf & _
"يجب أن يكون ممكنًا!")
إذن ما الذي يحدث هنا؟ الإجابة هي أن VB.NET يمنحك الإجابة الصحيحة رياضياً. رياضيا ، أنت يستطيع قسّم على الصفر ، لكن ما تحصل عليه هو "اللانهاية".
خافت أ ، ب ، ج كما مزدوجة
أ = 1: ب = 0
ج = أ / ب
وحدة التحكم. WriteLine (_
"الجواب هو: " _
& ج)
يعرض:
الجواب هو: اللانهاية
لا تعد قيمة "اللانهاية" مفيدة جدًا لمعظم تطبيقات الأعمال. (ما لم يكن الرئيس التنفيذي يتساءل عن الحد الأعلى لمكافأة الأسهم الخاصة به.) لكنه لا يمنع تطبيقاتك من التعطل في استثناء وقت التشغيل مثل اللغات الأقل قوة.
يمنحك VB.NET مرونة أكبر عن طريق السماح لك بإجراء العمليات الحسابية. تحقق من هذا:
خافت أ ، ب ، ج كما مزدوجة
أ = 1: ب = 0
ج = أ / ب
ج = ج + 1
"إنفينيتي زائد 1 هو
لا يزال لا نهاية
للمحافظة على صحة الحساب ، يمنحك VB.NET الإجابة NaN (ليس رقمًا) لبعض العمليات الحسابية مثل 0/0.
خافت أ ، ب ، ج كما مزدوجة
أ = 0: ب = 0
ج = أ / ب
وحدة التحكم. WriteLine (_
"الجواب هو: " _
& ج)
يعرض:
الجواب هو: NaN
يمكن لـ VB.NET أيضًا تحديد الفرق بين اللانهاية الإيجابية واللانهاية السلبية:
خافت a1 ، a2 ، ب ، ج كما مزدوجة
a1 = 1: a2 = -1: b = 0
إذا (a1 / b)> (a2 / b) ثم _
وحدة التحكم. WriteLine (_
"اللانهاية صالحهم بشكل ايجابي هو" _
& vbCrLf & _
"أكثر من" _
& vbCrLf & _
"اللانهاية السلبية.")
بالإضافة إلى PositiveInfinity و NegativeInfinity ، يوفر VB.NET أيضًا Epsilon ، أصغر قيمة مزدوجة موجبة أكبر من الصفر.
ضع في اعتبارك أن كل هذه الإمكانيات الجديدة لـ VB.NET متوفرة فقط مع أنواع بيانات الفاصلة العائمة (مزدوجة أو فردية). وهذه المرونة يمكن أن تؤدي إلى بعض التشويش Try-Catch-Last (معالجة خطأ منظم). على سبيل المثال ، يعمل رمز .NET أعلاه دون رمي أي نوع من الاستثناءات ، لذلك لن يساعد تشفيره داخل كتلة Try-Catch-وأخيرا. لاختبار قسمة على صفر ، يجب عليك رمز اختبار شيء مثل:
إذا ج. ToString = "Infinity" ثم...
حتى إذا قمت بتدوين البرنامج (باستخدام Integer بدلاً من أنواع مفردة أو مزدوجة) ، فلا تزال تحصل على استثناء "تجاوز سعة" ، وليس استثناء "Divide by Zero". إذا قمت بالبحث في الويب للحصول على مساعدة فنية أخرى ، فستلاحظ أن جميع الأمثلة تختبر OverflowException.
يحتوي .NET بالفعل على DivideByZeroException كنوع شرعي. ولكن إذا كانت الشفرة لا تؤدي مطلقًا إلى الاستثناء ، فمتى سترى هذا الخطأ بعيد المنال؟
عندما سترى DivideByZeroException
كما تبين، مايكروسوفتتستخدم صفحة MSDN الخاصة بتجربة Try-Catch-Final فعليًا قسمة على صفر أمثلة لتوضيح كيفية ترميزها. ولكن هناك "قبضة" خفية لا يفسرونها. رمزهم يشبه هذا:
خافت كعدد صحيح = 0
خافت b كـ عدد صحيح = 0
خافت ج كعدد صحيح = 0
محاولة
أ = ب \ ج
قبض exc كما استثناء
وحدة التحكم. WriteLine ("حدث خطأ في وقت التشغيل")
أخيرا
وحدة التحكم. ReadLine ()
محاولة النهاية
هذا الرمز هل اطلق قسمة فعلية على صفر استثناء.
ولكن لماذا تؤدي هذه الشفرة إلى الاستثناء ولا يوجد شيء قمنا بترميزه من قبل؟ وما هي مايكروسوفت لا تفسر؟
لاحظ أن العملية التي يستخدمونها هي ليس قسمة ("/") ، إنها عدد صحيح قسمة ("\")! (أمثلة أخرى من Microsoft تعلن بالفعل المتغيرات على أنها عدد صحيح.) كما اتضح ، حساب عدد صحيح هو فقط القضية التي يلقي فعلا هذا الاستثناء. كان من الجيد لو أن Microsoft (والصفحات الأخرى التي تنسخ الكود الخاص بها) أوضحت تلك التفاصيل الصغيرة.