java - क्या सिंटैक्स बैड प्रैक्टिस को संतुष्ट करने के लिए रिटर्न स्टेटमेंट है?




return try-catch (9)

निम्नलिखित कोड पर विचार करें:

public Object getClone(Cloneable a) throws TotallyFooException {

    if (a == null) {
        throw new TotallyFooException();
    }
    else {
        try {
            return a.clone();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
    }
    //cant be reached, in for syntax
    return null;
}

return null; यह आवश्यक है क्योंकि एक अपवाद को पकड़ा जा सकता है, हालांकि इस तरह के एक मामले में जब से हमने पहले ही जाँच की थी कि क्या यह अशक्त था (और हमें लगता है कि हम उस वर्ग को जानते हैं जिसे हम क्लोनिंग का समर्थन कहते हैं) तो हम जानते हैं कि कोशिश कथन कभी विफल नहीं होगा।

क्या सिंटैक्स को संतुष्ट करने और संकलित त्रुटियों से बचने के लिए अंत में अतिरिक्त रिटर्न स्टेटमेंट में डालना बुरा व्यवहार है (एक टिप्पणी के साथ यह समझा नहीं जा सकेगा), या क्या इस तरह से कुछ कोड करने का एक बेहतर तरीका है ताकि अतिरिक्त रिटर्न स्टेटमेंट अनावश्यक है


क्या सिंटैक्स को संतुष्ट करने और संकलन त्रुटियों से बचने के लिए अंत में अतिरिक्त रिटर्न स्टेटमेंट में डालना बुरा व्यवहार है (एक टिप्पणी के साथ यह समझा नहीं जाएगा)

मुझे लगता है कि एक अप्राप्य शाखा के टर्मिनस के लिए return null खराब अभ्यास है। एक RuntimeException ( AssertionError भी स्वीकार्य होगी) को फेंकना बेहतर है क्योंकि उस लाइन को प्राप्त करने के लिए कुछ बहुत गलत हो गया है और एप्लिकेशन अज्ञात स्थिति में है। ज्यादातर यह पसंद है (ऊपर की तरह) क्योंकि डेवलपर ने कुछ भी याद किया है (ऑब्जेक्ट कोई नहीं-शून्य और संयुक्त राष्ट्र के क्लोन नहीं हो सकते हैं)।

जब तक मुझे बहुत यकीन है कि कोड System.exit() उदाहरण के लिए एक System.exit() ) के बाद से जब तक यह अधिक संभावना है कि मैं VM की तुलना में एक गलती कर रहा हूँ, तो मैं InternalError उपयोग नहीं करूँगा।

मैं केवल एक कस्टम अपवाद का उपयोग करता हूँ (जैसे कि पूरी तरह से अपवाद) अगर उस "अगम्य रेखा" के लिए हो रही है तो इसका मतलब है कि कहीं और भी आप उस अपवाद को फेंक दें।


क्या सिंटैक्स बैड प्रैक्टिस को संतुष्ट करने के लिए रिटर्न स्टेटमेंट है?

जैसा कि दूसरों ने उल्लेख किया है, आपके मामले में यह वास्तव में लागू नहीं होता है।

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

    switch (var)
   {
     case A:
       break;
     default:
       return;
       break;    // Unreachable code.  Coding standard violation?
   }

एक ने शिकायत की कि ब्रेक नहीं होना एक मानक मानक उल्लंघन था। दूसरे ने शिकायत की कि यह एक था क्योंकि यह पहुंच से बाहर था।

मैंने इस पर ध्यान दिया क्योंकि दो अलग-अलग प्रोग्रामर ने कोड को ब्रेक जोड़ के साथ फिर से जाँचते रहे, फिर हटा दिया, फिर जोड़ा गया, फिर हटा दिया, जिसके आधार पर उस दिन वे किस कोड एनालाइज़र पर निर्भर थे।

यदि आप इस स्थिति में समाप्त होते हैं, तो एक को चुनें और विसंगति पर टिप्पणी करें, जो आपके द्वारा दिखाया गया अच्छा रूप है। यह सबसे अच्छा और सबसे महत्वपूर्ण takeaway है।


आपका उदाहरण आपके प्रश्न को स्पष्ट करने के लिए आदर्श नहीं है जैसा कि पिछले पैराग्राफ में कहा गया है:

क्या सिंटैक्स को संतुष्ट करने और संकलित त्रुटियों से बचने के लिए अंत में अतिरिक्त रिटर्न स्टेटमेंट में डालना बुरा व्यवहार है (एक टिप्पणी के साथ यह समझा नहीं जा सकेगा), या क्या इस तरह से कुछ कोड करने का एक बेहतर तरीका है ताकि अतिरिक्त रिटर्न स्टेटमेंट अनावश्यक है

एक बेहतर उदाहरण क्लोन के कार्यान्वयन का ही होगा:

 public class A implements Cloneable {
      public Object clone() {
           try {
               return super.clone() ;
           } catch (CloneNotSupportedException e) {
               throw new InternalError(e) ; // vm bug.
           }
      }
 }

यहां कैच क्लॉज को कभी दर्ज नहीं करना चाहिए। अभी भी वाक्यविन्यास को या तो कुछ फेंकने या एक मूल्य वापस करने की आवश्यकता है। चूँकि कुछ लौटाने का कोई मतलब नहीं है, इसलिए VM की गंभीर स्थिति को इंगित करने के लिए एक InternalError का उपयोग किया जाता है।


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


ऊपर दिए गए उदाहरण वैध हैं और बहुत जावा। हालाँकि, यहाँ बताया गया है कि मैं ओपी के सवाल को कैसे संबोधित करूँगा कि उस रिटर्न को कैसे संभाला जाए:

public Object getClone(Cloneable a) throws CloneNotSupportedException {
    return a.clone();
}

यह देखने के लिए कि क्या यह अशक्त है, जाँच के लिए कोई लाभ नहीं है। यह एनपीई के लिए जा रहा है। स्टैक ट्रेस प्रिंट करना भी उपयोगी नहीं है। स्टैक ट्रेस एक ही है, भले ही इसे संभाला जाए।

कोड को अनहेल्दी नल टेस्ट और अनहेल्फ़ अपवाद अपवाद हैंडलिंग के साथ जोड़ देने का कोई लाभ नहीं है। कबाड़ को हटाकर, वापसी मुद्दा मूक है।

(ध्यान दें कि ओपी में अपवाद हैंडलिंग में एक बग शामिल था; इस कारण रिटर्न की आवश्यकता थी। ओपी ने मेरे द्वारा प्रस्तावित विधि को गलत नहीं माना होगा।)


एक अतिरिक्त वापसी बयान के बिना एक स्पष्ट तरीका निम्नानुसार है। मैं CloneNotSupportedException भी नहीं पकड़ सकता, लेकिन इसे कॉलर को जाने दो।

if (a != null) {
    try {
        return a.clone();
    } catch (CloneNotSupportedException e) {
        e.printStackTrace();
    }
}
throw new TotallyFooException();

यह लगभग हमेशा संभव है कि आप जो कुछ भी शुरू करते हैं उससे अधिक सीधे-सीधे वाक्यविन्यास के साथ समाप्त करने के आदेश के साथ फिडेल करें।


मैं इसे फिर से लिखने के लिए लिखूंगा। स्यूडोकोड:

if a == null throw ...
// else not needed, if this is reached, a is not null
Object b
try {
  b = a.clone
}
catch ...

return b

मैं जाँच करने के लिए Objects.requireNonNull() का उपयोग करना पसंद Objects.requireNonNull() कि क्या पैरामीटर एक अशक्त नहीं है। इसलिए यह स्पष्ट है जब आप कोड पढ़ते हैं कि पैरामीटर शून्य नहीं होना चाहिए।

और चेक किए गए अपवादों से बचने के लिए मैं एक CloneNotSupportedException रूप में CloneNotSupportedException को फेंक CloneNotSupportedException

दोनों के लिए आप इस उद्देश्य के साथ अच्छा पाठ जोड़ सकते हैं कि ऐसा क्यों नहीं होना चाहिए या ऐसा नहीं होना चाहिए।

public Object getClone(Object a) {

    Objects.requireNonNull(a);

    try {
        return a.clone();
    } catch (CloneNotSupportedException e) {
        throw new IllegalArgumentException(e);
    }

}

यहाँ अभी तक किसी ने इसका उल्लेख नहीं किया है:

public static final Object ERROR_OBJECT = ...

//...

public Object getClone(Cloneable a) throws TotallyFooException {
Object ret;

if (a == null) 
    throw new TotallyFooException();

//no need for else here
try {
    ret = a.clone();
} catch (CloneNotSupportedException e) {
    e.printStackTrace();
    //something went wrong! ERROR_OBJECT could also be null
    ret = ERROR_OBJECT; 
}

return ret;

}

मुझे लगता है कि बहुत कारण के लिए ब्लॉक के अंदर return नापसंद करते return





try-catch