شرح مفصل للفرق بين الاستثناء الذي تم فحصه والاستثناء غير المحدد في جافا

(ط) التسلسل الهرمي لجافا

لفهم الفرق بين الاستثناء الذي تم فحصه والاستثناء غير المرغوب فيه في Java ، دعونا نلقي نظرة أولاً على التسلسل الهرمي لجافا.

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

(2) الفرق بين الاستثناء غير المحدد والاستثناء الذي تم فحصه

بعد فهم ما ورد أعلاه ، دعونا نلقي نظرة على الاستثناء الذي تم فحصه وما هو استثناء غير مرتاح. في الواقع ، تحدد مواصفات لغة Java هذين البسيطين للغاية. تسمى الاستثناءات المستمدة من الخطأ أو RunTimeException استثناءات غير محددة ، وجميع الاستثناءات الأخرى تصبح استثناءات محددة . على الرغم من أن هذا التعريف بسيط للغاية ، إلا أن RunTimeException هو مفهوم مربك للغاية. يبدو أن جميع استثناءاتنا بصدد تشغيل البرنامج. إن توضيحي لـ Ru ntimeexception في Java الفعالة ليس مرضيًا للغاية.

استخدم استثناءات محددة للظروف القابلة للاسترداد واستثناءات وقت التشغيل لأخطاء البرمجة (البند 58 في الإصدار الثاني)

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

(3) لماذا يجب أن نميز بين الاستثناءات غير المحددة والاستثناءات؟

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

(4) ما هي الاستثناءات التي يجب أن نعلنها؟

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

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

فيما يلي أمثلة لتوضيح الأشياء المحرجة المذكورة في الملاحظة 2 أعلاه:

أولاً ، حدد نوع استثناء أساسي genericexception ، الموروث من الاستثناء.

 Package Check_unchecked_exceptions ؛ فئة عامة Genericexception يمتد الاستثناء { / ** * * / private Static Final SerialVersionuid = 2778045265121433720l ؛ premitiSexception () {} genericexception (String msg) {super (msg) ؛ }}

فيما يلي يحدد فئة الاختبار VerifyException.

 حزمة check_unchecked_exceptions ؛ الفئة العامة VerifyException {public void first () يلقي genericexception {رمي genericexception جديد ("استثناء محدد") ؛ } public void Second (String msg) {if (msg == null) {رمي nullpointerxception جديد ("استثناء غير محدد") ؛ }} public void third () remingexexception {first () ؛ } public static void main (string [] args) {VerifyException ve = new VerifyException () ؛ حاول {ve.first () ؛ } catch (genericexception e) {E.PrintStackTrace () ؛ } ve.second (null) ؛ }}

بعد الجري ، احصل على المعلومات التالية على وحدة التحكم في Eclipse:

check_unchecked_exceptions.genericexception: استثناء محدد
في check_unchecked_exceptions.verifyexception.first (VerifyException.java:6)
في check_unchecked_exceptions.verifyexception.main (VerifyException.java:23)
استثناء في الموضوع "الرئيسي" java.lang.nullpointerexception
في check_unchecked_exceptions.verifyexception.second (VerifyException.java:11)
في check_unchecked_exceptions.verifyexception.main (VerifyException.java:29)

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

ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.