ما هي القاعدة العامة لإنشاء استثناء في Java؟

Question

لقد كنت في الحالتين:

• إنشاء عدد كبير جدًا من الاستثناءات المخصصة
• استخدام عدد كبير جدًا من فئات الاستثناءات العامة

في كلتا الحالتين، بدأ المشروع بشكل جيد ولكن سرعان ما أصبح بمثابة نفقات عامة يجب صيانتها (وإعادة بناءها).

إذن ما هي أفضل الممارسات فيما يتعلق بإنشاء فئات الاستثناء الخاصة بك؟

Answer 1

المتخصصين جافا كتب وظيفة عن الاستثناءات في جافا, ، وفيها يدرجون بعض "أفضل الممارسات" لإنشاء الاستثناءات، والتي تم تلخيصها أدناه:

• لا تكتب الاستثناءات الخاصة (هناك الكثير من الاستثناءات المفيدة التي تعد بالفعل جزءًا من Java API)

• كتابة الاستثناءات المفيدة (إذا كان عليك كتابة الاستثناءات الخاصة بك، فتأكد من أنها توفر معلومات مفيدة حول المشكلة التي حدثت)

Answer 2

لا تفعل ما فعله المطورون في شركتي.قام شخص ما بإنشاء [كذا] InvalidArguementException الذي يوازي java.lang.IllegalArgumentException، ونحن نستخدمه الآن (حرفيًا) في مئات الفئات.يشير كلاهما إلى أنه تم تمرير وسيطة غير قانونية أو غير مناسبة إلى طريقة ما.تحدث عن هدر...

جوشوا بلوخ يغطي هذا في دليل لغة برمجة جافا الفعال [كتابي المرجع الأول بشأن أفضل الممارسات] الفصل 8.الاستثناءات البند 42:يفضل استخدام الاستثناءات القياسية.وإليكم القليل مما يقوله

إعادة استخدام الاستثناءات الموجودة مسبقًا له فوائد عديدة.والأهم من ذلك، أنه يجعل واجهة برمجة التطبيقات (API) الخاصة بك أسهل في التعلم والاستخدام إنه يطابق الاتفاقيات الراسخة التي يعرفها المبرمجون بالفعل [تركيزي، وليس بلوخ].والأمر الثاني هو أن البرامج التي تستخدم واجهة برمجة التطبيقات (API) الخاصة بك تكون أسهل في القراءة لأنها لا تزدحم بالاستثناءات غير المألوفة.وأخيرًا، يعني عدد أقل من فئات الاستثناء مساحة ذاكرة أصغر ووقتًا أقل في تحميل الفئات.

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

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

كن ودودًا مع المبرمجين الذين يتعين عليهم الحفاظ على الكود الخاص بك في المستقبل.

Answer 3

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

try {
     doIt();
} catch (ExceptionType1 ex1) {
     // do something useful
} catch (ExceptionType2 ex2) {
     // do the exact same useful thing that was done in the block above
}

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

Answer 4

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

هذه هي القاعدة الأساسية بالنسبة لي.

Answer 5

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

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

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

Answer 6

قاعدتي الخاصة:

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

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

Answer 7

أثناء إنشاء الاستثناء الخاص بك:

• يجب أن تكون جميع الاستثناءات تابعة لـ فئة قابلة للرمي

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

• إذا كنت تريد كتابة استثناء لوقت التشغيل، فأنت بحاجة إلى تمديد فئة استثناء وقت التشغيل.

Answer 8

لا تأكل الاستثناءات، ارميها https://stackoverflow.com/a/921583/1097600

تجنب إنشاء الاستثناء الخاص بك.استخدم العناصر أدناه الموجودة بالفعل.

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

رمي الاستثناءات غير المحددة.

مثال

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}