रक्षात्मक प्रोग्रामिंग और अपवाद हैंडलिंग

Question

एक जोड़े दिन पहले, मैं परीक्षा पर सैद्धांतिक प्रश्नों निम्नलिखित है: (क) के बारे में बताएं क्या रक्षात्मक प्रोग्रामिंग का क्या मतलब है जब असाधारण परिस्थितियों एक कार्यक्रम के निष्पादन के दौरान हो सकता है कि के साथ काम कर। उदाहरण के लिए फ़ाइल पढ़ने की कोशिश करते समय आप कुछ परिस्थितियों को रोकने के लिए किए गए चरणों का वर्णन करने के लिए कक्षाओं में देखे गए उदाहरणों का उपयोग कर सकते हैं या छद्म कोड का उपयोग कर सकते हैं। [5 अंक]

(बी) सामान्य शब्दों में संक्षेप में वर्णन करें कि जावा में अपवाद हैंडलिंग और यह रक्षात्मक प्रोग्रामिंग से अलग कैसे है। [5 अंक]

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

Answer 1

मेरे लिए रक्षात्मक प्रोग्रामिंग, उन मामलों को संभालने के लिए कोड लिखना है जो आपको नहीं लगता है, या यहां तक ​​कि ऐसा भी हो सकता है, क्योंकि आपको विश्वास है कि आपकी खुद की मान्यताओं अविश्वसनीय हैं।

उदाहरण के लिए (संकलित या परीक्षण नहीं, नियम और शर्तें लागू):

private String findSmallestString(Collection<String> strings) { 
    if (strings == null || strings.isEmpty()) return null; 
    Iterator<String> stringsIt = strings.iterator(); 
    try { 
     String smallestString = stringsIt.next(); 
     while (stringsIt.hasNext()) { 
      String candidateString = stringsIt.next(); 
      if (candidateString == null) continue; 
      if (candidateString.compareTo(smallestString) < 0) { 
       smallestString = candidateString; 
      } 
     } 
     return smallestString; 
    } 
    catch (NoSuchElementException e) { 
     return null; 
    } 
} 

वहाँ में, यकीनन बचाव की मुद्रा में विशेषताओं में शामिल हैं: शीर्ष पर

• अशक्त या खाली गार्ड खंड ; यह एक निजी विधि है, इसलिए आपको यह सुनिश्चित करने की स्थिति में होना चाहिए कि इसे कभी भी शून्य या खाली संग्रह के साथ नहीं कहा जाता है
• NoSuchElementException के लिए प्रयास करें; आप यह साबित कर सकते हैं कि इसमें शामिल कोड इस अपवाद को कभी नहीं फेंक देगा अगर इटरेटर अपने अनुबंध को पूरा करता है।
• तारों पर शून्यता गार्ड क्लॉज (पहले के अलावा!) इटरेटर से बाहर आ रहा है; फिर से, के बाद से यह एक निजी विधि है, तो आप शायद यह सुनिश्चित करें कि संग्रह पैरामीटर nulls शामिल सक्षम होना चाहिए (और क्या आप संग्रह में nulls डाल कर रहे होते वैसे भी?)

हर कोई है कि रिक्त सहमत होंगे चेक रक्षात्मक हैं। कोशिश-पकड़ पूरी तरह से व्यर्थ होने के बिंदु पर है।

मेरे लिए, रक्षात्मक प्रोग्रामिंग का एसिड परीक्षण यह है कि आपको नहीं लगता कि रक्षा का कभी भी उपयोग किया जाएगा।

Answer 2

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

हर दिन, सॉफ्टवेयर उद्योग बड़ा और बेहतर मूर्ख-प्रमाणक सॉफ्टवेयर बना रहा है, और हर दिन, प्रकृति बड़ी और बेहतर मूर्ख बनाती है। अब तक प्रकृति

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

हम सब विफल रहा है इकाई परीक्षण नष्ट कर दिया के बाद भी, इस कार्यक्रम काम नहीं किया