عند كتابة برامج Java ، يُطلب من الاستثناءات عادةً أن يتم اكتشافها ، ولا تحتاج بعض الاستثناءات إلى الوقوع بالقوة. الأشخاص الذين تم نقلهم من لغات أخرى مثلي يشعرون بالارتباك بعض الشيء ، لذلك سأعيد تفسيرها في فهمي.
فئة الاستثناء الأساسية هي استثناء ، والفئات الفرعية الاستثناء تشمل RunTimeException وغيرها من الاستثناءات. تسمى هذه الاستثناءات الأخرى الاستثناءات المحددة ، ويسمى RunTimeException استثناءات غير محددة.
ليس من السهل أن نفهم فقط من خلال النظر إلى الاسم. يعرف المترجم أن جميع الأنواع أو الأساليب قد ترمي استثناءات ، وعندما تستخدم نوعًا أو طريقة معينة ، سيطالبك برنامج التحويل البرمجي بالقبض على استثناءات معروفة. الاستثناء المحتمل المعروف لهؤلاء المترجمين هو الاستثناء الذي تم فحصه. على سبيل المثال ، عند إغلاق دفق الملفات ، ذكر IOException بالفعل في الطريقة الإغلاق التي قد يتم إلقاؤها ، ويطالبك المترجم بأن الاستثناء يجب أن يتم اكتشافه. لا يُعرف استثناء RunTimeException خلال مرحلة التجميع ، ولا يمكن تحديده إلا خلال مرحلة الجري. لأن هذا المقسوم يمكن تغييره في مرحلة الجري ، لا يوجد موجه للقبض. هذه runtimeexpections هي استثناءات غير مرتاح.
باختصار ، ستقوم Java بجعل البرنامج مستقرًا قدر الإمكان. يجب أن يكون هذا التفسير أكثر وضوحًا.
دعنا نصل إلى هذه النقطة.
ربما واجه بعض الأصدقاء هذا الموقف عند تصحيح البرنامج. لا يوجد سببان فقط: 1. مؤشر الترابط الذي يوجد فيه الاستثناء ليس هو نفس مؤشر الترابط الذي تصطاده ، 2. لا يلقي البرنامج استثناء بل خطأ. خطأ ، مثل الاستثناء ، يرث من رمي ، يشير إلى خطأ خطير لا ينبغي القبض عليه. عندما رأيت هذا التفسير ، كنت غبيًا جدًا لدرجة أنني لم أفهم لماذا لا ينبغي أن ألتقط الخطأ. نظرًا لحدوث خطأ ، لن يتم تشغيل البرنامج مباشرة ، لذلك لا معنى له. ثم تأتي مشكلتي مرة أخرى. في الواقع ، هذا الافتراض ليس صحيحًا ، لأنه إذا كان الخطأ موجودًا بالفعل ، فستكتشف مشكلات في بيئة التطوير ومن المستحيل نشرها على البيئة الرسمية.
للأسف ، لقد تجاوزت شوطًا طويلاً وفعلت مثل هذا الشيء الغبي ، لذلك لا تناقش ما إذا كان ينبغي التقاط الخطأ!
ما زلت على دراية والغرض من الكتابة هو الحصول على إرشادات الجميع. إذا كانت المقالة تساعدك ، فسيكون ذلك رائعًا.