java.lang.Exception बनाम अपना खुद का अपवाद रोलिंग

Question

आप किस बिंदु पर java.lang.Exception का उपयोग कर अपना अपवाद वर्ग बनाम बनायेंगे? (हर समय? केवल अगर यह पैकेज के बाहर इस्तेमाल किया जाएगा? केवल अगर इसमें उन्नत तर्क होना चाहिए? आदि ...)

Answer 1

मुझे लगता है कि आपको खुद को एक छोटे से अलग सवाल पूछने की ज़रूरत है "नया क्या नया फायदा बनाता है अपवाद मुझे या डेवलपर्स जो मेरे कोड का उपयोग करते हैं? " असल में एकमात्र लाभ यह आपको या अन्य लोगों को अपवाद को संभालने की क्षमता देता है। यह एक स्पष्ट उत्तर की तरह लगता है लेकिन वास्तव में यह नहीं है। आपको केवल उन अपवादों को संभालना चाहिए जिन्हें आप उचित रूप से पुनर्प्राप्त कर सकते हैं। यदि आपके द्वारा फेंक दिया गया अपवाद वास्तव में घातक त्रुटि है तो डेवलपर्स को इसे गलत तरीके से संभालने का मौका क्यों देता है? गहराई से चर्चा में

अधिक: Custom exceptions: When should you create them?

Answer 2

जब मैं बाकी सब के से अलग ढंग से मेरी अपवाद का इलाज करना चाहते हैं। अगर मैं अपना पकड़ना चाहता हूं और हर किसी के प्रचार करना चाहता हूं, या अगर मैं किसी और को पकड़ना चाहता हूं और मेरा प्रचार करना चाहता हूं, या यदि मैं दोनों को पकड़ना चाहता हूं लेकिन उन्हें अलग-अलग व्यवहार करना चाहता हूं, तो मैं अपने अपवादों के लिए एक अलग वर्ग परिभाषित करूंगा। अगर मैं उन दोनों का इलाज करना चाहता हूं, दोनों या तो दोनों को पकड़कर या पकड़े हुए अपवादों के साथ एक ही चीज़ कर कर), मैं मानक वर्ग का उपयोग करूंगा।

Answer 3

ज्यादातर मामलों में यह आपकी अपवाद कक्षा बनाने के लिए समझ में नहीं आता है।

नौसिखिया प्रोग्रामर में अपनी खुद की अपवाद कक्षा बनाने के लिए एक प्रवृत्ति है ताकि वे ऐसे नाम का उपयोग कर सकें जो त्रुटि के प्रकार का अधिक संकेतक हो। तो आपको FTPInitializationException, DAOFactoryException आदि जैसी कक्षाएं मिलेंगी, भले ही ऐसे अपवादों को मानक अपवादों से अलग तरीके से संभाला नहीं जा रहा है। यह स्पष्ट रूप से एक विरोधी पैटर्न है जिसे टालना चाहिए।

Answer 4

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

1. पहली बार कोई विधि बनाते समय, बस अपवादों को पार करने दें।

2. यदि ऐसे अपवाद हैं जिन्हें संभाला जाना चाहिए, तो उन्हें या तो कुछ रनटाइम अपवाद या लपेटकर स्वयं को फेंकने के लिए लपेटा जा सकता है। मैं कई मामलों में रनटाइम अपवाद पसंद करता हूं। एपीआई बिंदु दृश्य से इसकी आवश्यकता होने तक परिभाषित परिभाषा को परिभाषित किया जाना चाहिए।

3. बाद में जब कुछ कॉलर में अपवाद के लिए विशिष्ट हैंडलिंग करने की आवश्यकता होती है, तो वापस आएं और इसके लिए नया अपवाद बनाएं।

बिंदु जानते हुए भी क्या जरूरत है इससे पहले कि अतिरिक्त काम कर रही से बचने के लिए है।

Answer 5

यदि भाषा रनटाइम या पुस्तकालयों के साथ एक मौजूदा अपवाद है, तो इसका उपयोग करें ELSE अपना स्वयं का बनाएं, इसे अच्छी तरह से दस्तावेज करें और इसे 99% मामलों में काम करना चाहिए।

Answer 6

कारण एक:

विशिष्ट सामान को पकड़ने के लिए की आवश्यकता है। यदि कॉलिंग कोड को एक विशिष्ट असाधारण स्थिति से निपटने की आवश्यकता है, तो आपको अपनी अपवाद को अलग करने की आवश्यकता है, और जावा अलग-अलग प्रकार के अपवादों को अलग करता है, इसलिए आपको अपना खुद लिखना होगा।

असल में, अगर किसी को लिखने के लिए है: आप शायद एक विशिष्ट एक्सटेंशन लिखना चाहते

catch(ExistingException e) { 
    if({condition}) { 
    { some stuff here} 
    } 
    else { 
    { different stuff here} 
    } 
} 

; पकड़ अपवाद मिलान सशर्त, आईएमएचओ से स्पष्ट है।

याद रखें:

एपीआई समेकन: अपने नए अपवाद RuntimeException

की

कारण दो एक उपवर्ग हो सकता है। आप एक इंटरफेस लिखने और आप कई कार्यान्वयन है, तो यह संभव है कि वे फेंक दिया विभिन्न गैर RuntimeExceptions की एक पूरी गुच्छा के साथ विभिन्न एपीआई कॉल करेगा:

interface MyInterface { 
    void methodA(); 
} 

class MyImplA { 
    void methodA() throws SQLException { ... } 
} 

class MyImplB { 
    void methodA() throws IOException { ... } 
} 

तुम सच में MyInterface.methodA SQLException और IOException फेंक करना चाहते हैं? हो सकता है कि कस्टम अपवाद में संभावित अपवादों को लपेटना समझ में आता है। जो फिर से एक रनटाइम अपवाद हो सकता है। या यहां तक ​​कि RuntimeException खुद ...

Answer 7

जब अपवाद एपीआई से संबंधित होता है तो मैं जावा एपीआई से अपवादों का उपयोग करता हूं। लेकिन अगर एक असाधारण स्थिति उत्पन्न होती है जो कि मेरे अपने एपीआई के लिए अद्वितीय है तो मैं इसके लिए एक अपवाद तैयार करूंगा। उदाहरण के लिए यदि मेरे पास दो गुणों के साथ एक रेंज ऑब्जेक्ट न्यूनतम और अधिकतम है और invariant min < = अधिकतम तो मैं एक अपवाद अमान्य रेंज अपवाद बनाउंगा।

जब मैं कोड लिख रहा हूं तो इससे मदद मिलती है क्योंकि मुझे पता है कि अपवाद उत्पन्न होता है क्योंकि मैंने अपनी शर्तों में से एक या जावा एपीआई से इसका उल्लंघन किया है।

Answer 8

मुझे विश्वास है कि:

catch (Exception e) { 
    ... 
} 

... एक antipattern कि परहेज किया जाना चाहिए है। आप एक त्रुटि को लॉग इन करने और पूरे एप्लिकेशन को समाप्त होने से रोकने के लिए, अपने आवेदन में कहीं एक केंद्रीकृत व्यापक पकड़ चाहते हैं - लेकिन उन्हें विचित्र-बिली के आसपास बिखरे हुए बुरे हैं।

क्यों:

try { 
    if(myShape.isHidden()) { 
     throw new Exception(); 
    } 
    // More logic 
} catch (Exception e) { 
    MyApp.notify("Can't munge a hidden shape"); 
} 

तो आप इस प्रयास करें, और एक कोडिंग त्रुटि के कारण, myShape रिक्त है। रनटाइम myShape को खराब करने का प्रयास करता है जब एक NullPointerException फेंक दिया जाता है। यह कोड एक छिपे हुए आकार की रिपोर्ट करता है, जब इसे एक शून्य सूचक की रिपोर्ट करनी चाहिए।

या तो अपना अपवाद बनाएं, या एपीआई में एक उपयुक्त विशेष अपवाद पाएं। ऐसा नहीं है कि अपवाद या रनटाइम अपवाद का विस्तार करना कठिन है।

Answer 9

मैं कल्पना नहीं कर सकता कि विशेष रूप से java.lang.Exception फेंक रहा है अगर कुछ ऑब्जेक्ट/क्लास/विधि में कोई समस्या है। यह बहुत सामान्य है - यदि आप अपनी खुद की अपवाद कक्षा नहीं बना रहे हैं, तो मुझे लगता है कि कम से कम एपीआई में एक विशिष्ट विशिष्ट अपवाद-प्रकार होना चाहिए।

Answer 10

सॉफ़्टवेयर अर्थ कैप्चर करता है।

मौजूदा अपवाद फेंकने के लगभग कोई कारण नहीं हैं: JVM पहले से ही आपके लिए ऐसा करता है। उनके अपवाद का आपका संस्करण वास्तव में सटीक नहीं है और "अपवाद" फेंकना अर्थपूर्ण नहीं है।

आपके पास लिखा गया पार्सिंग एल्गोरिदम की वजह से आपके पास DataFormatException हो सकता है। हालांकि, यह दुर्लभ है।

जब आपका प्रोग्राम एक असाधारण स्थिति का सामना करता है, तो यह आपके कार्यक्रम के लिए लगभग हमेशा अद्वितीय होता है। मौजूदा अपवाद में अपनी असाधारण स्थिति को मजबूर क्यों करें? यदि यह आपके कार्यक्रम के लिए अद्वितीय है, तो ... अच्छा ... यह अद्वितीय है। इस तरह से नाम दें।

हालांकि, प्रत्येक अद्वितीय संदेश के लिए एक अद्वितीय अपवाद वर्ग प्रदान नहीं करते हैं। एक अपवाद वर्ग में कई प्रकार के संदेश और सहायक विवरण हो सकते हैं।

अंगूठे का पाइथन नियम, जावा में अनुवादित, पैकेज स्तर पर किसी भी अद्वितीय अपवाद को परिभाषित करना है। [पायथन में, वे "मॉड्यूल" स्तर पर अपवादों का सुझाव देते हैं, जो कुछ जावा में सटीक रूप से अनुवाद नहीं करते हैं।]