यदि कार्यों को खराब व्यवहार करने से पहले अशक्त जांच करना है तो क्या यह खराब डिजाइन है?

Question

इसलिए मुझे नहीं पता कि यह अच्छा या बुरा कोड डिज़ाइन है, इसलिए मुझे लगा कि मैं बेहतर पूछना चाहता हूं।

मैं अक्सर ऐसी विधियाँ बनाता हूँ जो डेटा प्रोसेसिंग कक्षाओं को शामिल करती हैं और मैं अक्सर तरीकों में बहुत सारी जाँच करता हूँ ताकि यह सुनिश्चित कर सकूँ कि मुझे हाथ से पहले अशक्त संदर्भ या अन्य त्रुटियाँ नहीं मिलीं।

एक बहुत ही बुनियादी उदाहरण के लिए:

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

तो जैसा कि आप हर बार नल की जाँच कर सकते हैं। लेकिन क्या विधि में यह जांच नहीं होनी चाहिए?

उदाहरण के लिए बाहरी कोड को हाथ से पहले डेटा को साफ करना चाहिए ताकि विधियों को नीचे की तरह मान्य करने की आवश्यकता न हो:

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

सारांश में, विधियों को "डेटा सत्यापन" होना चाहिए और फिर डेटा पर उनका प्रसंस्करण करना चाहिए, या विधि को कॉल करने से पहले इसकी गारंटी दी जानी चाहिए, और यदि आप विधि को कॉल करने से पहले मान्य करने में विफल रहते हैं, तो यह एक त्रुटि फेंकनी चाहिए (या इसे पकड़ना चाहिए) त्रुटि)?

Comments

क्या होता है जब कोई अशक्त जांच करने में विफल रहता है और सेटनाम किसी भी तरह से एक अपवाद फेंकता है?

— रॉबर्ट हार्वे

अगर मैं वास्तव में कुछ अशक्त होना चाहता हूँ तो क्या होगा ? आप यह तय करते हैं कि आप क्या चाहते हैं, या तो कुछ भी अशक्त हो सकता है, या यह नहीं हो सकता है, और फिर आप अपने कोड को तदनुसार लिख सकते हैं। यदि आप चाहते हैं कि यह कभी अशक्त न हो, तो आप चेक को मुखर रूप से बदल सकते हैं।

— gnasher729

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

— मर्गिसिसा जूल

C # 8 के साथ, आपको संभावित रूप से सही सेटिंग्स के साथ अशक्त संदर्भ अपवादों के बारे में चिंता करने की आवश्यकता नहीं होगी: blogs.msdn.microsoft.com/dotnet/2017/11/15/…

— JᴀʏMᴇᴇ

यह एक कारण है कि C # भाषा टीम

— अशक्त

Answer 1

आपके मूल उदाहरण के साथ समस्या शून्य जांच नहीं है, यह मौन विफल है ।

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

1. चेकिंग को परेशान न करें, और रनटाइम को नलपॉइंट अपवाद छोड़ दें।
2. मूल एनपीई संदेश की तुलना में बेहतर संदेश के साथ एक अपवाद की जाँच करें और फेंक दें।

एक तीसरा समाधान अधिक काम है, लेकिन बहुत अधिक मजबूत है:

3. अपनी कक्षा की संरचना ऐसी करें कि _someEntityकिसी अमान्य स्थिति में होना हमेशा असंभव हो। ऐसा करने का एक तरीका यह है कि इससे छुटकारा पाएं AssignEntityऔर इसे तात्कालिकता के लिए एक पैरामीटर के रूप में आवश्यकता होती है। अन्य निर्भरता इंजेक्शन तकनीक के रूप में अच्छी तरह से उपयोगी हो सकता है।

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

यदि तीसरा विकल्प कोई विकल्प नहीं है, तो मेरी राय में यह वास्तव में तब तक मायने नहीं रखता है जब तक यह चुपचाप विफल नहीं होता है। यदि नल की जाँच न करना कार्यक्रम को तुरंत विस्फोट करने का कारण बनता है, तो ठीक है, लेकिन यदि यह चुपचाप डेटा को सड़क के नीचे परेशानी पैदा करने के लिए भ्रष्ट कर देता है, तो यह जाँच करना और उसके बाद सही तरीके से निपटना सबसे अच्छा है।

Comments

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

— whatsisname

"क्योंकि आपका कोड टूट गया है क्योंकि यह nullठीक से नहीं चल रहा है" - यह एक गलतफहमी है कि उचित हैंडलिंग का क्या मतलब है। अधिकांश जावा प्रोग्रामर के लिए, इसका मतलब है कि किसी भी अवैध इनपुट के लिए एक अपवाद फेंकना । जब तक तर्क के रूप में चिह्नित नहीं किया जाता है, तब तक @ParametersAreNonnullByDefaultइसका उपयोग भी प्रत्येक के लिए nullहोता है @Nullable। कुछ और करने का अर्थ है कि मार्ग को लंबा करना जब तक कि यह अंत में कहीं और न उड़ जाए और इस तरह डिबगिंग पर बर्बाद होने वाले समय को भी लंबा कर दे। ठीक है, समस्याओं को अनदेखा करके, आप यह प्राप्त कर सकते हैं कि यह कभी भी नहीं उड़ता है, लेकिन गलत व्यवहार तब बहुत गारंटी देता है।

— Maaartinus

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

— jpmc26

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

— डिओगो कोल्लॉस

@aroth आपका कोड टूट गया है क्योंकि इसके पास मेरा कोड एक अशक्त है जब यह एक ऐसी चीज से गुजर रहा होना चाहिए जिसका नाम संपत्ति के रूप में है। विस्फोट के अलावा कोई भी व्यवहार किसी प्रकार का बैकडोर बिज़ारो-डायनामिक टाइपिंग आईएमएचओ का विश्व संस्करण है।

— मलबिग

Answer 2

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

इस समस्या के लिए एक दृष्टिकोण इसलिए भी अधिक रक्षात्मक है और निम्न में से एक करना है:

1. _someEntityविधि के माध्यम से कॉपी और संदर्भ की एक स्थानीय प्रतिलिपि बनाएँ,
2. _someEntityयह सुनिश्चित करने के लिए चारों ओर एक ताला का उपयोग करें कि यह विधि के रूप में परिवर्तित नहीं होता है,
3. विधि के भीतर होने वाली try/catchकिसी भी कार्रवाई का उपयोग करें और NullReferenceExceptionजैसा कि आप प्रारंभिक नल जांच (इस मामले में, एक nopकार्रवाई) में करेंगे।

लेकिन आपको वास्तव में क्या करना चाहिए रोकना चाहिए और अपने आप से सवाल पूछना चाहिए: क्या आपको वास्तव में _someEntityअधिलेखित होने की अनुमति देने की आवश्यकता है ? कंस्ट्रक्टर के माध्यम से इसे एक बार सेट क्यों नहीं किया जाता है। इस तरह, आपको केवल कभी-कभी उस शून्य जांच की आवश्यकता है:

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

यदि संभव हो तो, यह ऐसी स्थितियों में लेने की सलाह देता हूं। यदि आप संभव nulls को संभालने के लिए चुनते समय थ्रेड सुरक्षा के प्रति जागरूक नहीं हो सकते।

एक बोनस टिप्पणी के रूप में, मुझे लगता है कि आपका कोड अजीब है और इसमें सुधार किया जा सकता है। के सभी:

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

के साथ प्रतिस्थापित किया जा सकता है:

public Entity SomeEntity { get; set; }

जिसकी एक ही कार्यक्षमता है, एक अलग नाम के साथ विधि के बजाय, संपत्ति सेटर के माध्यम से फ़ील्ड को सेट करने में सक्षम होने के लिए सहेजें।

Comments

यह प्रश्न का उत्तर क्यों देता है? प्रश्न अशक्त जाँच को संबोधित करता है और यह एक कोड समीक्षा के लिए बहुत अधिक है।

— IEatBagels

@TopinFrassi यह बताता है कि वर्तमान अशक्त जाँच दृष्टिकोण थ्रेड सुरक्षित नहीं है। यह तब अन्य रक्षात्मक प्रोग्रामिंग तकनीकों को छूता है जो कि चारों ओर मिलता है। फिर यह पहली जगह में उस रक्षात्मक प्रोग्रामिंग की आवश्यकता से बचने के लिए अपरिवर्तनीयता का उपयोग करने के सुझाव के साथ लपेटता है। और एक अतिरिक्त बोनस के रूप में, यह सलाह देता है कि कोड को बेहतर ढंग से कैसे तैयार किया जाए।

— डेविड अर्नो

Answer 3

लेकिन क्या विधि में यह जांच नहीं होनी चाहिए?

यह आपकी पसंद है।

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

आप किस प्रकार का अनुबंध डिजाइन करना चाहते हैं, यह आप पर निर्भर है। महत्वपूर्ण चीजें हैं

• एक एपीआई बनाएं जो उपयोगी और सुसंगत हो और

• इसे अच्छी तरह से दस्तावेज़ करने के लिए, विशेष रूप से उन किनारे के मामलों के लिए।

आपके मामले को किस तरह से बुलाया जा रहा है?

Comments

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

— डेडुप्लिकेटर

Answer 4

अन्य उत्तर अच्छे हैं; मैं एक्सेसिबिलिटी मॉडिफायर के बारे में कुछ टिप्पणी करके उन्हें विस्तार देना चाहता हूं। अगर nullवैध नहीं है तो सबसे पहले क्या करें :

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

• आंतरिक और निजी तरीकों उन तुम कहाँ है फोन करने वाले नियंत्रित करते हैं। अशक्त होने पर उन्हें जोर देना चाहिए ; वे शायद बाद में दुर्घटनाग्रस्त हो जाएंगे, लेकिन कम से कम आपको पहले जोर मिला, और डिबगर में टूटने का अवसर मिला। फिर से, आप अपने कॉलर्स को प्रशिक्षित करना चाहते हैं कि वे आपको सही तरीके से कॉल करें जब उन्हें चोट न लगे।

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

उदाहरण के लिए, आप इस स्थिति में नहीं रहना चाहते:

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

और कॉल साइट पर:

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

क्योंकि (1) आप अपने कॉलर्स को प्रशिक्षित कर रहे हैं कि अशक्तता एक अच्छा मूल्य है, और (2) यह स्पष्ट नहीं है कि उस मूल्य के शब्दार्थ क्या हैं। बल्कि, ऐसा करें:

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

और अब कॉल साइट इस तरह दिखती है:

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

और अब कोड का पाठक जानता है कि इसका क्या मतलब है।

Comments

बेहतर अभी तक, ifअशक्त वस्तुओं के लिए एस की एक श्रृंखला नहीं है, बल्कि उन्हें सही ढंग से व्यवहार करने के लिए बहुरूपता का उपयोग करें।

— कोनराड रूडोल्फ

@KonradRudolph: वास्तव में, यह अक्सर एक अच्छी तकनीक है। मैं डेटा संरचनाओं के लिए इसका उपयोग करना पसंद करता हूं, जहां मैं एक EmptyQueueप्रकार बनाता हूं जो कि छंटने पर फेंकता है, और इसी तरह।

— एरिक लिपर्ट

@EricLippert - मुझे माफ़ कर देना क्योंकि मैं अभी भी यहाँ सीख रहा हूँ, लेकिन मान लीजिये अगर Personवर्ग अपरिवर्तनीय था, और इसमें एक शून्य तर्क निर्माता नहीं था, तो आप अपने ApproverNotRequiredया ApproverUnknownउदाहरणों का निर्माण कैसे करेंगे ? दूसरे शब्दों में, आप निर्माता को किन मूल्यों से गुजारेंगे?

मैं एसई के पार आपके जवाब / टिप्पणियों से टकराता हूं, वे हमेशा आनंदित रहते हैं। जैसे ही मैंने आंतरिक / निजी तरीकों के लिए जोर लगाते हुए देखा मैंने उम्मीद की कि यह एरिक लिपर्ट जवाब होगा, निराश नहीं हुआ :)

— बॉब एस्पोनाजा

आप लोग मेरे द्वारा दिए गए विशिष्ट उदाहरण पर विचार कर रहे हैं। यह जल्दी से भर में अशक्त वस्तु पैटर्न के विचार प्राप्त करना था। यह एक कागजात और पेचेक स्वचालन प्रणाली में अच्छे डिजाइन का उदाहरण नहीं था। एक वास्तविक प्रणाली में, "अनुमोदन" करने से टाइप "व्यक्ति" शायद एक बुरा विचार है क्योंकि यह व्यवसाय प्रक्रिया से मेल नहीं खाता है; कोई अनुमोदन नहीं हो सकता है, आपको कई की आवश्यकता हो सकती है, और इसी तरह। जैसा कि मैं अक्सर उस डोमेन में प्रश्नों का उत्तर देते समय ध्यान देता हूं, जो हम वास्तव में चाहते हैं वह एक नीति वस्तु है। उदाहरण पर लटका मत करो।

— एरिक लिपर्ट

Answer 5

अन्य उत्तर बताते हैं कि आपके कोड को एक साफ़ जाँच की ज़रूरत नहीं है कि आपके पास यह कहाँ है, हालाँकि, एक सामान्य उत्तर के लिए एक उपयोगी उत्तर जाँच के लिए निम्नलिखित नमूना कोड पर विचार कर सकते हैं:

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

यह आपको रखरखाव के लिए एक लाभ देता है। यदि कभी आपके कोड में कोई खराबी आती है, जहां कोई विधि के लिए एक अशक्त वस्तु को पास करता है, तो आपको विधि से उपयोगी जानकारी प्राप्त होगी कि कौन सा पैरामीटर अशक्त था। चेक के बिना, आपको लाइन पर एक NullReferenceException मिलेगी:

a.Something = b.Something;

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

मैं नोट करूंगा कि आपके मूल कोड में पैटर्न:

if (x == null) return;

कुछ विशेष परिस्थितियों में इसके उपयोग हो सकते हैं, यह (संभवतः अधिक बार) आपको अपने कोडबेस में अंतर्निहित मुद्दों को मास्क करने का एक बहुत अच्छा तरीका दे सकता है।

Answer 6

नहीं, बिल्कुल नहीं, लेकिन यह निर्भर करता है।

यदि आप इस पर प्रतिक्रिया करना चाहते हैं तो आप केवल एक संदर्भ संदर्भ जांच करते हैं।

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

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

Answer 7

@ Null के उत्तर के विस्तार के बारे में कुछ, लेकिन मेरे अनुभव में, नल कोई फर्क नहीं पड़ता कि जाँच करें।

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

अब, आप वास्तव में एक nullमूल्य के साथ कैसे व्यवहार करते हैं , यह आपके उपयोग के मामले पर बहुत अधिक निर्भर करता है।

यदि nullस्वीकार्य मान है, उदाहरण के लिए MSVC दिनचर्या _splitpath () के लिए पांचवें मापदंडों के माध्यम से दूसरे में से कोई भी, तो चुपचाप इसके साथ व्यवहार करना सही व्यवहार है।

यदि nullप्रश्न में दिनचर्या को कॉल करते समय कभी भी ऐसा नहीं होना चाहिए, यानी ओपी के मामले में एपीआई अनुबंध को AssignEntity()वैध के साथ बुलाया जाना चाहिए Entity, तो एक अपवाद फेंक दें, या अन्यथा यह सुनिश्चित करने में विफल रहें कि आप इस प्रक्रिया में बहुत अधिक शोर करते हैं।

कभी भी अशक्त जांच की लागत के बारे में चिंता न करें, यदि वे ऐसा करते हैं, तो वे सस्ते में गंदगी करते हैं, और आधुनिक संकलक के साथ, स्थैतिक कोड विश्लेषण कर सकते हैं और पूरी तरह से उन्हें खत्म कर देंगे यदि संकलक निर्धारित करता है कि यह होने वाला नहीं है।

Comments

या इसे पूरी तरह से बचने के (: 48 मिनट 29 सेकेंड "कभी कभी उपयोग करें या अपने कार्यक्रम के एक नल पॉइंटर के पास कहीं भी अनुमति दें" )।

— पीटर मोर्टेंसन