कॉलर में इनपुट पैरामीटर की मान्यता: कोड दोहराव?

16

फ़ंक्शन के इनपुट मापदंडों को मान्य करने के लिए सबसे अच्छी जगह कहां है: कॉलर में या फ़ंक्शन में ही?

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

मेरी पिछली परियोजनाओं में, हम फ़ंक्शन के अंदर प्रत्येक इनपुट पैरामीटर की जांच और इलाज करते थे, (उदाहरण के लिए यदि यह शून्य नहीं है)। अब, मैंने यहाँ कुछ उत्तरों में और प्रोगैमैटिक प्रोग्रामर पुस्तक में भी पढ़ा है, कि इनपुट पैरामीटर की मान्यता कॉलर की जिम्मेदारी है।

तो इसका मतलब है, कि मुझे फ़ंक्शन को कॉल करने से पहले इनपुट मापदंडों को मान्य करना चाहिए। हर जगह फ़ंक्शन कहा जाता है। और यह एक सवाल खड़ा करता है: क्या यह हर जगह फ़ंक्शन को चेक करने की स्थिति का दोहराव नहीं बनाता है?

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

क्या कुछ नियम हैं कि इनपुट स्थिति की जांच करने के लिए कैसे तय किया जाए?

मैं कुछ तर्कों के बारे में सोच रहा हूँ:

जब अमान्य वैरिएबल का उपचार अलग-अलग हो सकता है, तो इसे कॉलर साइड में मान्य करना अच्छा होता है (जैसे sqrt()फ़ंक्शन - किसी मामले में मैं जटिल संख्या के साथ काम करना चाहता हूं, इसलिए मैं कॉलर में स्थिति का इलाज कर सकता हूं)
जब हर कॉलर में चेक की स्थिति समान होती है, तो डुप्लिकेट से बचने के लिए, फ़ंक्शन के अंदर इसकी जांच करना बेहतर होता है
कॉलर में इनपुट पैरामीटर की मान्यता इस पैरामीटर के साथ कई फ़ंक्शन को कॉल करने से पहले केवल एक ही होती है। इसलिए प्रत्येक फ़ंक्शन में एक पैरामीटर का सत्यापन प्रभावी नहीं है
सही समाधान विशेष मामले पर निर्भर करता है

मुझे उम्मीद है कि यह प्रश्न किसी अन्य का डुप्लिकेट नहीं है, मैंने इस मुद्दे की खोज की और मुझे इसी तरह के प्रश्न मिले लेकिन उन्होंने इस मामले का बिल्कुल उल्लेख नहीं किया।

coding-standards validation dry

— srnka
स्रोत

15

निर्भर करता है। विधि द्वारा निहित अनुबंध (या प्रलेखित) के विवरण और ताकत पर आधारित होना चाहिए । मान्यता एक विशिष्ट अनुबंध के पालन का एक अच्छा तरीका है। यदि किसी भी कारण से विधि में बहुत सख्त अनुबंध है, तो हाँ, यह आपको कॉल करने से पहले जांचना है।

यह एक विशेष रूप से महत्वपूर्ण अवधारणा है जब आप एक सार्वजनिक विधि बनाते हैं , क्योंकि आप मूल रूप से विज्ञापन कर रहे हैं कि कुछ विधि कुछ ऑपरेशन करती है। यह बेहतर है कि आप जो कहते हैं वह करता है!

उदाहरण के रूप में निम्न विधि अपनाएँ:

public void DeletePerson(Person p)
{            
    _database.Delete(p);
}

अनुबंध किसके द्वारा निहित है DeletePerson? प्रोग्रामर केवल यह मान सकता है कि यदि कोई Personपास हो गया है, तो उसे हटा दिया जाएगा। हालाँकि, हम जानते हैं कि यह हमेशा सच नहीं होता है। क्या होगा अगर pएक nullमूल्य है? यदि pडेटाबेस में मौजूद नहीं है तो क्या होगा ? यदि डेटाबेस काट दिया जाता है तो क्या होगा? इसलिए, DeletePerson अपने अनुबंध को अच्छी तरह से पूरा करने के लिए प्रकट नहीं होता है। कभी-कभी, यह एक व्यक्ति को हटा देता है, और कभी-कभी यह एक NullReferenceException, या एक डेटाबेसनोटकनेक्टेड अपवाद को फेंकता है, या कभी-कभी यह कुछ भी नहीं करता है (जैसे कि व्यक्ति पहले ही हटा दिया गया है)।

इस तरह के एपीआई का उपयोग करना बेहद मुश्किल है, क्योंकि जब आप किसी विधि के इस "ब्लैक बॉक्स" को कॉल करते हैं, तो सभी प्रकार की भयानक चीजें हो सकती हैं।

यहाँ कुछ तरीके हैं जिनसे आप अनुबंध में सुधार कर सकते हैं:

सत्यापन जोड़ें और अनुबंध में अपवाद जोड़ें। यह अनुबंध को मजबूत बनाता है , लेकिन इसके लिए आवश्यक है कि कॉलर सत्यापन को पूरा करे। हालांकि, अंतर यह है कि अब वे अपनी आवश्यकताओं को जानते हैं। इस मामले में मैं इसे C # XML टिप्पणी के साथ संवाद करता हूं, लेकिन आप इसके बजाय एक throws(जावा) जोड़ सकते हैं , एक का उपयोग कर सकते हैं Assert, या कोड अनुबंध जैसे अनुबंध उपकरण का उपयोग कर सकते हैं।
```
///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    _database.Delete(p);
}
```
_{साइड नोट: इस शैली के खिलाफ तर्क अक्सर यह होता है कि यह सभी कॉलिंग कोड द्वारा अत्यधिक पूर्व-मान्यता का कारण बनता है, लेकिन मेरे अनुभव में यह अक्सर ऐसा नहीं होता है। ऐसे परिदृश्य के बारे में सोचें जहां आप एक अशक्त व्यक्ति को हटाने की कोशिश कर रहे हैं। ये कैसे हो गया? अशक्त व्यक्ति कहाँ से आया? यदि यह UI है, उदाहरण के लिए, यदि वर्तमान चयन नहीं है, तो Delete कुंजी को क्यों संभाला गया था? यदि इसे पहले ही हटा दिया गया था, तो क्या इसे पहले ही प्रदर्शन से हटा दिया जाना चाहिए था? जाहिर है कि इसके अपवाद हैं, लेकिन एक परियोजना के रूप में आप अक्सर इस तरह से कोड को धन्यवाद देंगे जैसे कि कीड़े को सिस्टम में गहराई से रोकने के लिए।}
सत्यापन और कोड रक्षात्मक रूप से जोड़ें। यह अनुबंध को शिथिल बना देता है , क्योंकि अब यह विधि केवल व्यक्ति को हटाने से अधिक करती है। मैंने इसे दर्शाने के लिए विधि का नाम बदल दिया है, लेकिन यदि आप अपने एपीआई में संगत हैं तो यह आवश्यक नहीं हो सकता है। इस दृष्टिकोण के अपने पेशेवरों और विपक्ष हैं। यह कहा जा रहा है कि अब आप TryDeletePersonसभी प्रकार के अमान्य इनपुट से गुजर सकते हैं और अपवादों की चिंता कभी नहीं कर सकते । बेशक, यह है कि आपके कोड के उपयोगकर्ता शायद इस पद्धति को बहुत अधिक कहेंगे, या यह उन मामलों में डिबगिंग को मुश्किल बना सकता है जहां पी अशक्त है। इसे सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल का एक हल्का उल्लंघन माना जा सकता है , इसलिए अगर कोई युद्ध लड़ता है तो इसका ध्यान रखें।
```
public void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}
```
संयुक्त दृष्टिकोण। कभी-कभी आप दोनों को थोड़ा चाहते हैं, जहां आप चाहते हैं कि बाहरी कॉलर्स नियमों का बारीकी से पालन करें (उन्हें जिम्मेदार कोड करने के लिए मजबूर करें), लेकिन आप चाहते हैं कि आपका निजी कोड लचीला हो।
```
///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    TryDeletePerson(p);
}

internal void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}
```

मेरे अनुभव में, एक कठिन नियम के बजाय आपके द्वारा किए गए अनुबंधों पर ध्यान केंद्रित करना सबसे अच्छा काम करता है। रक्षात्मक कोडिंग उन मामलों में बेहतर काम करती दिखाई देती है, जहाँ कॉल करने वाले के लिए यह निर्धारित करना कठिन या कठिन है कि कोई ऑपरेशन वैध है या नहीं। सख्त अनुबंध बेहतर काम करते दिखाई देते हैं जहाँ आप उम्मीद करते हैं कि कॉलर केवल मेथड कॉल तभी करें जब वे वास्तव में, वास्तव में समझ में आ जाएँ।

— केविन मैककॉर्मिक
स्रोत

उदाहरण के साथ बहुत अच्छे उत्तर के लिए धन्यवाद। मुझे "रक्षात्मक" और "सख्त अनुबंध" दृष्टिकोण की बात पसंद है।

— snnka

7

यह सम्मेलन, प्रलेखन और उपयोग के मामले की बात है।

सभी कार्य समान नहीं हैं। सभी आवश्यकताएं समान नहीं हैं। सभी सत्यापन समान नहीं हैं।

उदाहरण के लिए, यदि आपका जावा प्रोजेक्ट जब भी संभव हो तो अशक्त बिंदुओं से बचने की कोशिश करता है ( उदाहरण के लिए, अमरूद शैली की सिफारिशें देखें ), क्या आप अभी भी यह सुनिश्चित करने के लिए प्रत्येक फ़ंक्शन तर्क को मान्य करते हैं कि यह अशक्त नहीं है? यह शायद आवश्यक नहीं है, लेकिन संभावना है कि आप अभी भी इसे करते हैं, बग को खोजने के लिए आसान बनाने के लिए। लेकिन आप एक मुखर का उपयोग कर सकते हैं जहां आपने पहले NullPointerException को फेंक दिया था।

क्या होगा यदि परियोजना C ++ में है? C ++ में कन्वेंशन / परंपरा प्रीकॉन्डिशन को प्रलेखित करने के लिए है, लेकिन केवल डिबग बिल्ड में उन्हें (यदि सभी में) सत्यापित करें।

किसी भी स्थिति में, आपके पास अपने फ़ंक्शन पर एक प्रलेखित पूर्व शर्त है: कोई भी तर्क अशक्त नहीं हो सकता है। आप इसके बजाय परिभाषित व्यवहार के साथ नल को शामिल करने के लिए फ़ंक्शन का डोमेन बढ़ा सकते हैं, उदाहरण के लिए "यदि कोई तर्क शून्य है, तो एक अपवाद फेंकता है"। बेशक, यह फिर से मेरी C ++ धरोहर है जो यहां बोल रही है - जावा में, यह इस तरह से पूर्व शर्त दस्तावेज़ करने के लिए पर्याप्त है।

लेकिन सभी पूर्व शर्त भी यथोचित जाँच नहीं की जा सकती। उदाहरण के लिए, एक द्विआधारी खोज एल्गोरिदम में पूर्व शर्त है कि खोजे जाने वाले अनुक्रम को क्रमबद्ध किया जाना चाहिए। लेकिन यह पुष्टि करते हुए कि यह निश्चित रूप से एक ओ (एन) ऑपरेशन है, इसलिए ऐसा करने पर हर कॉल थोड़े में पहले स्थान पर एक ओ (लॉग (एन)) एल्गोरिथ्म का उपयोग करने के बिंदु को हरा देता है। यदि आप रक्षात्मक रूप से प्रोग्रामिंग कर रहे हैं, तो आप कम जांच कर सकते हैं (उदाहरण के लिए यह सत्यापित करें कि आपके द्वारा खोज किए गए प्रत्येक विभाजन के लिए, प्रारंभ, मध्य और अंत मान सॉर्ट किए गए हैं), लेकिन यह सभी त्रुटियों को नहीं पकड़ता है। आमतौर पर, आपको बस उस शर्त पर भरोसा करना होगा जो पूरी हो रही है।

एक वास्तविक स्थान जहाँ आपको स्पष्ट जाँच की आवश्यकता होती है, सीमाओं पर है। आपके प्रोजेक्ट के लिए बाहरी इनपुट? मान्य करें, मान्य करें, मान्य करें। एक ग्रे क्षेत्र एपीआई सीमाएं है। यह वास्तव में इस बात पर निर्भर करता है कि आप क्लाइंट कोड पर कितना विश्वास करना चाहते हैं, अवैध इनपुट कितना नुकसान पहुंचाता है और बग ढूंढने में आप कितनी सहायता करना चाहते हैं। किसी भी विशेषाधिकार सीमा को बाहरी रूप से गिना जाना चाहिए, बेशक - syscalls, उदाहरण के लिए, एक उन्नत विशेषाधिकार संदर्भ में चलते हैं और इसलिए इसे सत्यापित करने के लिए बहुत सावधान रहना चाहिए। इस तरह के किसी भी सत्यापन को निश्चित रूप से syscall के लिए आंतरिक होना चाहिए।

— सेबस्टियन रेडल
स्रोत

आपके उत्तर के लिए धन्यवाद। क्या आप, अमरूद शैली की सिफारिश के लिए लिंक दे सकते हैं? मैं गूगल नहीं कर सकता और पता लगा सकता हूं कि आपके पास इसका क्या मतलब है। सीमाओं की पुष्टि के लिए +1।

— snnka

जोड़ा गया लिंक। यह वास्तव में एक पूर्ण शैली गाइड नहीं है, गैर-शून्य उपयोगिताओं के प्रलेखन का एक हिस्सा है।

— सेबस्टियन रेडल

6

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

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

— बर्नार्ड
स्रोत

उत्तर के लिए धन्यवाद। तो आपको लगता है, उस फ़ंक्शन को हर मामले में वैध और अमान्य दोनों इनपुट मापदंडों की जांच करनी चाहिए। व्यावहारिक प्रोग्रामर पुस्तक पुष्टि से कुछ अलग: "इनपुट पैरामीटर की मान्यता कॉलर की जिम्मेदारी है"। यह अच्छा है "फ़ंक्शन को पता होना चाहिए कि क्या मान्य माना जाता है ... कॉलर्स को यह पता नहीं हो सकता है" ... तो आप पूर्व स्थितियों का उपयोग करना पसंद नहीं करते हैं?

— snnka

1

यदि आप चाहें तो पूर्व-स्थितियों का उपयोग कर सकते हैं ( सेबेस्टियन का उत्तर देखें ), लेकिन मैं रक्षात्मक रहना पसंद करता हूं और किसी भी तरह के संभावित इनपुट को संभालना चाहता हूं।

— बर्नार्ड

4

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

इसके अलावा, यदि फ़ंक्शन को इस तरह से अपडेट किया जाता है जो पैरामीटर के सत्यापन को प्रभावित करेगा, तो आपको उन्हें अपडेट करने के लिए कॉलर सत्यापन की प्रत्येक घटना की खोज करनी होगी। यह प्यारा :-) नहीं है।

आप गार्ड क्लॉज का उल्लेख कर सकते हैं

अपडेट करें

आपके द्वारा प्रदत्त प्रत्येक परिदृश्य के लिए मेरा उत्तर देखें।

जब अमान्य वैरिएबल का उपचार अलग-अलग हो सकता है, तो इसे कॉलर साइड में मान्य करना अच्छा होता है (जैसे sqrt()फ़ंक्शन - किसी मामले में मैं जटिल संख्या के साथ काम करना चाहता हूं, इसलिए मैं कॉलर में स्थिति का इलाज कर सकता हूं)

उत्तर

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

इसके अलावा, sqrtअधिकांश प्रोग्रामिंग भाषाओं के लिए पहले से ही लागू किया गया है, इसलिए आप इसे संशोधित नहीं कर सकते हैं, और यदि आप कार्यान्वयन को बदलने का प्रयास करते हैं (बंदर पैचिंग देखें), तो आपके सहयोगी sqrtअचानक नकारात्मक संख्याओं को स्वीकार करने पर जोरदार झटका देंगे ।

यदि आप एक चाहते थे तो आप इसे अपने कस्टम sqrtफ़ंक्शन के चारों ओर लपेट सकते हैं जो नकारात्मक संख्या को संभालता है और जटिल संख्या देता है।
जब हर कॉलर में चेक की स्थिति समान होती है, तो डुप्लिकेट से बचने के लिए, फ़ंक्शन के अंदर इसकी जांच करना बेहतर होता है

उत्तर

हां, यह आपके कोड में पैरामीटर सत्यापन को बिखरने से बचाने के लिए एक अच्छा अभ्यास है।
कॉलर में इनपुट पैरामीटर की मान्यता इस पैरामीटर के साथ कई फ़ंक्शन को कॉल करने से पहले केवल एक ही होती है। इसलिए प्रत्येक फ़ंक्शन में एक पैरामीटर का सत्यापन प्रभावी नहीं है

उत्तर

यह अच्छा होगा यदि कॉलर एक फ़ंक्शन है, क्या आपको नहीं लगता है?

यदि कॉलर के भीतर के फ़ंक्शन अन्य कॉलर द्वारा उपयोग किए जाते हैं, तो आपको कॉल करने वाले फ़ंक्शन के भीतर पैरामीटर को मान्य करने से क्या रोकता है?
सही समाधान विशेष मामले पर निर्भर करता है

उत्तर

अनुरक्षण कोड के लिए निशाना लगाओ। अपने पैरामीटर सत्यापन को आगे बढ़ाने से सच्चाई का एक स्रोत सुनिश्चित होता है कि फ़ंक्शन क्या स्वीकार कर सकता है या नहीं।

— OnesimusUnbound
स्रोत

उत्तर के लिए धन्यवाद। Sqrt () सिर्फ एक उदाहरण था, इनपुट पैरामीटर के साथ समान व्यवहार का उपयोग कई अन्य कार्यों द्वारा किया जा सकता है। "यदि फ़ंक्शन को इस तरह से अपडेट किया जाता है जो पैरामीटर के सत्यापन को प्रभावित करेगा, तो आपको कॉलर सत्यापन की प्रत्येक घटना की खोज करनी होगी" - मैं इससे सहमत नहीं हूं। फिर हम रिटर्न वैल्यू के लिए भी यही कह सकते हैं: यदि फ़ंक्शन को इस तरह से अपडेट किया जाता है जो रिटर्न वैल्यू को प्रभावित करेगा, तो आपको हर कॉलर को सही करना होगा ... मुझे लगता है कि फ़ंक्शन को एक अच्छी तरह से परिभाषित कार्य करना होगा ... अन्यथा वैसे भी कॉलर में बदलाव जरूरी है।

— srnka

2

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

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

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

यद्यपि पहली नज़र में कॉलर में चेक कोड दोहराव को आमंत्रित करने के लिए लगता है, यह वास्तव में चारों ओर का दूसरा तरीका है। कोड डुप्लिकेट में कैली परिणाम में जांच और बहुत सारे अनावश्यक काम किए जा रहे हैं।
बस इसके बारे में सोचें, आप कितनी बार फ़ंक्शन की कई परतों के माध्यम से पैरामीटर पास करते हैं, जिससे उनमें से कुछ के साथ केवल छोटे बदलाव होते हैं। यदि आप लगातार चेक-इन-केली विधि लागू करते हैं , तो उन मध्यवर्ती कार्यों में से प्रत्येक को प्रत्येक पैरामीटर के लिए चेक को फिर से करना होगा।
और अब कल्पना करें कि उन मापदंडों में से एक को एक क्रमबद्ध सूची माना जाता है।
कॉलर में चेक के साथ, केवल पहले फ़ंक्शन को यह सुनिश्चित करना होगा कि सूची वास्तव में क्रमबद्ध है। अन्य सभी जानते हैं कि सूची पहले से ही क्रमबद्ध है (जैसा कि उन्होंने अपनी पूर्व स्थिति में बताया है) और आगे की जाँच के बिना इसे पारित कर सकते हैं।

— बार्ट वैन इनगेन शेनौ
स्रोत

+1 जवाब के लिए धन्यवाद। अच्छा प्रतिबिंब: "कोड डुप्लिकेट में कैली के परिणाम की जांच और बहुत सारे अनावश्यक काम किए जा रहे हैं"। और वाक्य में: "ज्यादातर मामलों में, कोई स्पष्ट परीक्षण की आवश्यकता नहीं है क्योंकि आंतरिक तर्क और कॉलर की पूर्व-शर्तें पहले से ही सुनिश्चित करती हैं" - अभिव्यक्ति "आंतरिक तर्क" से आपका क्या मतलब है? DBC कार्यक्षमता?

— snnka

@ सर्नका: "आंतरिक तर्क" के साथ मेरा मतलब है कि एक फ़ंक्शन में गणना और निर्णय। यह अनिवार्य रूप से फ़ंक्शन का कार्यान्वयन है।

— बार्ट वैन इनगेन शेनॉ

0

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

फिर भी, यदि आप जिस भाषा का उपयोग अपवादों का उपयोग करते हैं, तो आप कुछ त्रुटियों के लिए जाँच नहीं कर सकते हैं और सुनिश्चित करें कि एक अपवाद को फेंक दिया जाएगा, लेकिन इस मामले में आपको दस्तावेज़ में मामले का वर्णन करना ज़रूरी है (आपको दस्तावेज़ीकरण की आवश्यकता है)। अपवाद से कॉलर को पर्याप्त जानकारी मिल जाएगी कि क्या हुआ था, और अमान्य तर्कों पर भी ध्यान जाएगा।

— Superm
स्रोत

वास्तव में, पैरामीटर को मान्य करना बेहतर हो सकता है, और, यदि पैरामीटर अमान्य है, तो स्वयं एक अपवाद फेंक दें। यहाँ ऐसा क्यों है: जो लोग कुछ निश्चित करने के लिए परेशान किए बिना अपनी दिनचर्या कहते हैं, उन्होंने इसे वैध डेटा दिया है वही लोग हैं जो त्रुटि रिटर्न कोड की जांच करने के लिए परेशान नहीं होंगे जो इंगित करते हैं कि वे अमान्य डेटा पारित कर चुके हैं। अपवाद फेंकने से समस्या ठीक हो जाती है।

— जॉन आर। स्ट्रोहम