जावा, कक्षा-विशिष्ट अपवाद बनाम मानक अपवाद

Question

मैं लाइब्रेरी का उपयोग कर लोगों द्वारा डीबगिंग में सुधार करने में सहायता के लिए अपवाद फेंकने के लिए मौजूदा लाइब्रेरी अपडेट कर रहा हूं।

पहले, मैंने सोचा कि मैं प्रत्येक वर्ग के लिए विशिष्ट अपवादों को परिभाषित करता हूं, हालांकि यह पता चलता है कि इनमें से अधिकतर अपवाद मौजूदा संदेशों के साथ मौजूदा रनटाइम अपवादों (उदाहरण के लिए, FooNegativeIntArgumentException extends IllegalArgumentException, FooNullBarException extends NullPointerException) के एक्सटेंशन हैं।

मौजूदा अपवादों का उपयोग कर नए अपवादों को परिभाषित करने के व्यापार-बंद क्या हैं? क्या कोई सम्मेलन/सर्वोत्तम प्रथाएं हैं?

इसके अलावा, पिछली संगतता की आवश्यकता को देखते हुए, इन अपवादों के अधिकांश (यदि नहीं सभी) रनटाइम अपवाद हैं।

Answer 1

यहां my take on why we have different types of exception and when to create custom exception types (नोट: यह उदाहरण के रूप में .NET प्रकारों का उपयोग करता है लेकिन समान सिद्धांत जावा और किसी अन्य भाषा पर लागू होते हैं जो संरचित त्रुटि प्रबंधन का उपयोग करता है)।यहां एक पूर्ण उत्तर के रूप में पोस्ट करना शायद बहुत लंबा है इसलिए मैं केवल दो प्रमुख निष्कर्षों को पोस्ट करूंगा।

1. जब अपवाद के विभिन्न प्रकार फेंकने के लिए? प्रत्येक लक्षण के लिए एक अलग प्रकार के अपवाद फेंको जिसे प्रोग्रामेटिक रूप से अलग-अलग संभाला जा सकता है।

2. कस्टम अपवाद प्रकार कब बनाएं? लक्षण के प्रोग्रामेटिक हैंडलिंग में सहायता के लिए अतिरिक्त जानकारी के साथ अपवाद को एनोटेट करने की आवश्यकता होने पर कस्टम अपवाद प्रकार बनाएं।

अपने मामले में यह अपने कस्टम अपवाद प्रकार की तरह ध्वनि नहीं करता लक्षण है कि मानक अपवाद का उपयोग कर अवगत करा दिया जा सकता है में एक अंतराल को भरने के हैं, और वे कार्यक्रम संबंधी से निपटने के लिए कोई अतिरिक्त जानकारी जोड़ने नहीं कर रहे हैं, तो उन्हें मत बनाओ। बस इसके बजाय मानक का उपयोग करें।

Answer 2

इस तरह के किसी भी मूल्य को जोड़ने के बिना अपवादों को विस्तारित करना समय की पूरी बर्बादी है और एक चल रहे रखरखाव लागत को सबसे अच्छी तरह से बचाया जाता है।

मानक अपवादों का उपयोग करें।

यह कहना नहीं है कि आपको कभी भी कस्टम अपवादों का उपयोग नहीं करना चाहिए, केवल आपके द्वारा पेश किए जाने वाले उपयोग मामलों में नहीं।

साथ ही, जब कस्टम अपवाद बनाते हैं, तो उन्हें उन स्थितियों से संबंधित होना चाहिए, जिनके कारण उन्हें कक्षा में फेंक दिया जा सकता है। उन्हें व्यवसाय/कार्यात्मक क्षेत्र से जोड़ना ठीक है, क्योंकि त्रुटियों की वजह से त्रुटियों की संभावनाएं इस तरह से संबंधित हैं, और यह उपयोगी फ़िल्टरिंग तकनीक प्रदान करेगी।

Answer 3

व्यापार-बंद? बहुत सारे काम, बनाए रखने के लिए बहुत सारे कोड और समय धन है। मैं सुझाव दूंगा: केवल नए अपवादों को परिभाषित करें यदि आपको उन्हें फ़िल्टर फ़िल्टर करने, ठीक दाग अपवाद हैंडलिंग या डिबगिंग (विशेष अपवाद प्रकार के लिए ब्रेकपॉइंट सेट करें) की आवश्यकता होती है।

Answer 4

मैं क्लाइंट कोड को अधिक नियंत्रण देने के लिए स्पष्ट रूप से परिभाषित अपवादों का उपयोग करता हूं। यदि ग्राहक चाहता है, तो वे ऊपर दिए गए उदाहरण में IllegalArgumentException पकड़ सकते हैं। अगर उन्हें अधिक नियंत्रण की आवश्यकता है, तो वे अलग-अलग प्रकार के अपवादों को पकड़ सकते हैं। उदाहरण के लिए, एक विधि जो IllegalArgumentException के दो उप-वर्गों को फेंक सकती है पर विचार करें। यदि आप उपclass नहीं करते हैं, तो आपको फेंकने वाले अपवाद के वास्तविक कारण को निर्धारित करने के लिए स्ट्रिंग पार्सिंग या कुछ अन्य बकवास करना होगा। उपयोगकर्ता द्वारा परिभाषित प्रकार इस मुद्दे को हल करते हैं।

Answer 5

क्या यह संभव है कि एक कॉलर को IllegalArgumentException की बजाय FooNegativeIntArgumentException को पकड़ने की आवश्यकता होगी?

मेरा अनुमान है कि यह लगभग कभी नहीं होगा, इसलिए जब तक आपके पास ऐसे मामले नहीं हैं जहां ऐसी भिन्नता की आवश्यकता हो, तब तक मैं बुनियादी अपवादों के साथ रहूंगा।

Answer 6

Effective Java

से आप मानक अपवाद के उपयोग के पक्ष में और जावा मंच अनियंत्रित अपवाद को कवर किया है कि तुम क्या वर्णित का सेट पुस्तकालयों का उपयोग करना चाहिए। अपवाद पुनर्प्रयोग निम्नलिखित लाभ हैं:

अपने एपीआई आसान जानने के लिए और क्योंकि यह स्थापित परंपराओं जिसके साथ प्रोग्रामर पहले से ही परिचित

कम अपवाद कक्षाएं एक छोटे स्मृति पदचिह्न और कम समय खर्च लोड हो रहा है कक्षाओं का मतलब कर रहे हैं से मेल खाता उपयोग करने के लिए बनाता है।