تنقسم استثناءات Java إلى فئتين: استثناء فحص واستثناء وقت التشغيل. الاستثناءات التي تم فحصها هي استثناءات يمكن معالجتها أثناء مرحلة التجميع.
الفرق والاتصال بين الاستثناء المحدد واستثناء وقت التشغيل
فصول الاستثناء المشتركة
اذكر عدة استثناءات شائعة في وقت التشغيل:
اذكر العديد من الاستثناءات غير المحددة (استثناءات محددة):
خطأ
يشير الخطأ بشكل عام إلى المشكلات المتعلقة بالأجهزة الافتراضية ، مثل حوادث النظام ، وأخطاء الجهاز الظاهري ، وفشل الارتباط الديناميكي ، وما إلى ذلك. لا يمكن استرداد هذا الخطأ أو لا يمكن التقاطه ، مما سيؤدي إلى انقطاع التطبيق. عادةً ما لا يمكن للتطبيقات التعامل مع هذه الأخطاء ، لذلك يجب ألا يحاول البرنامج استخدام Catch للقبض على كائن الخطأ. ليست هناك حاجة لإلقاء كائن الخطأ عند تحديد طريقة.
استخدام الاستثناءات المحددة
كما ذكرنا سابقًا ، يجب معالجة الفحص بشكل صريح ، وإلا سيتم الإبلاغ عن خطأ التجميع ، مثل إعلان دفق إدخال الملف:
FileInputStream fis = new FileInputStream ("test.md") ؛سيتم تجميع هذا الرمز بخطأ
نوع الاستثناء غير المعدل fileNotfoundException
لذلك ، يجب التعامل معها بشكل صريح ، وهناك عمومًا طريقتان للتعامل مع الاستثناءات المحددة:
إذا كنت تعرف كيفية التعامل معها ، فمن الأفضل استخدام المحاولة ... catch ... block processing:
// يجب التعامل مع الاستثناء المحدد بشكل صريح {fileInputStream fis = new FileInputStream ("test.md") ؛} catch (fileNotfoundException e) {eprintstacktrace () ؛ system.out.println ("الملف غير موجود!") ؛}إذا كنت لا تعرف كيفية التعامل معها ، فقم برميها بالطريقة والتعامل معها بواسطة المتصل السابق:
يجب التعامل مع الاستثناء الفراغ الثابت العام (سلسلة [] args) fileNotFoundException {// الاستثناء الذي تم فحصه بشكل صريح // يتم إلقاء الاستثناء في الطريقة الرئيسية ويسلمه إلى JVM للمعالجة. طريقة JVM للتعامل مع استثناءات هي طباعة معلومات مكدس التتبع وإنهاء البرنامج لتشغيل FileInputStream FIS = جديد fileInputStream ("Test.MD") ؛} استخدم رمي لرمي الاستثناءات بنفسك
في بعض الأحيان ، وفقًا لاحتياجات العمل ، سنقوم بإلقاء استثناءات في البرنامج من قبل أنفسنا. على سبيل المثال ، إذا كان محتوى ملف القراءة فارغًا ، فإننا نعتقد أن هذا استثناء. في هذا الوقت ، يمكننا استخدام رمي لرمي الاستثناء بنشاط والقبض عليه:
// استخدم رمي لرمي استثناء بفعالية جرب {fileInputStream fis = new FileInputStream ("test.md") ؛ if (fis.read () == 0) {رمي ioException جديد ("ملف فارغ") ؛ }} catch (ioException e) {E.PrintStackTrace () ؛}إذا رمي رمي استثناء وقت التشغيل ، يمكن اكتشاف البرنامج مع المحاولة ... التقاط ... أو تجاهله.
معالجة سلسلة الاستثناء
في التطبيقات الحقيقية على مستوى المؤسسة ، لا نقوم غالبًا بفضح الاستثناءات الأساسية للتطبيقات ذات المستوى الأعلى ، مثل عدم تعريض استثناءات SQL لواجهة المستخدم. أولاً ، بالنسبة للمستخدمين ، فإن رؤية استثناءات SQL ليست مفيدة لهم ، والثاني ، بالنسبة للمستخدمين الخبيثين ، ليس من الآمن كشف الاستثناءات الأساسية.
إذن كيف تمنع الاستثناء الأساسي؟ الممارسة المعتادة هي: البرنامج أولاً يمسك بالاستثناء الأصلي ، ثم يلقي استثناءًا جديدًا للعمل. يحتوي استثناء العمل الجديد على معلومات سريعة للمستخدم. تصبح طريقة التعامل هذه ترجمة استثناء. يوضح ما يلي كيف يقوم البرنامج الذي ينشئ المستخدم بحظر الاستثناء الأساسي:
// إظهار سلسلة الاستثناءات وإنشاء Void Public CreateSubscriber (int subid) يلقي BusinessException {try {// إنشاء منطق المستخدم ...} catch (استثناء e) {// العملية وحفظ الاستثناء الأصلي ... // أعلى استثناء عمل جديد رمي الأعمال التجارية الجديدة ("فشل إنشاء المستخدم") ؛ }}يمكنك أن ترى أن البرنامج يخفي الاستثناء الأصلي ويوفر فقط معلومات موجه الاستثناء اللازم لأعلى ، والذي يمكن أن يضمن عدم تمديد الاستثناء الأساسي إلى طبقة العرض التقديمي ، والذي يتماشى تمامًا مع مبدأ التغليف للكائن.
هذا النوع من التقاط استثناء واحد ، ورمي استثناء آخر ، وحفظ معلومات الاستثناء الأصلية هو معالجة سلسلة نموذجية ، والتي تسمى نمط سلسلة المسؤولية في نمط التصميم.
عدة اقتراحات لاستخدام الاستثناءات
نستخدم استثناءات لتحقيق عدة أهداف:
لمعالجة هذه الأهداف ، ينبغي لنا:
1. لا تفرط في الاستخدام أو تعتمد عليه: الاستثناءات مريحة للغاية ، ولكن لا تستخدم معالجة الاستثناء للمنطق العادي ، مثل
// الكود الأصلي if (filesize> 100) {sysotem.out.println ("الملف كبير جدًا ، يرجى التحميل مرة أخرى") ؛ متابعة ؛} // تغيير لاستثناء الاستثناء إذا (filesize> 100) {رمي استثناء جديد ("الملف كبير جدًا ، يرجى التحميل مرة أخرى") ؛} // من الواضح أن القيام بذلك غير مسؤول.