2010-09-13 17 views
10

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

प्रश्न यह है कि उचित() उचित रूप से उपयोग करने के लिए आवेदन करने के लिए अच्छे सिद्धांत क्या हैं? एक assert() का उपयोग करना उचित कब है और यह कब नहीं है? क्या मानदंडों की एक सूची है कि वैध होने के लिए प्रत्येक दावे को पारित किया जाना चाहिए? हम जोर() के उचित उपयोग को कैसे प्रोत्साहित कर सकते हैं?

इस पर पहली क्रैक के रूप में, मैं कहूंगा कि जोर() का उपयोग केवल ऐसी स्थिति को दस्तावेज करने के लिए किया जाना चाहिए जो पहुंचने के लिए असंभव माना जाता है और इसे रन टाइम पर एक जोर() विफलता के रूप में पहचाना जाना चाहिए कभी उठने के लिए क्योंकि प्रोग्रामिंग मान्यताओं का उल्लंघन किया जा रहा है।

क्या लोग इससे बेहतर कर सकते हैं? जोर() के साथ आपका अनुभव क्या है?

+3

जब आप जानते हैं कि कोड को "अच्छा" माना जाने के लिए कुछ शर्त प्रबल होनी चाहिए, तो जोर दें। अगर जोर विफल रहता है, तो परिभाषा के अनुसार कोड तय किया जाना चाहिए। –

+1

@ रॉबर्ट: +1 पर सहमत हुए, लेकिन इस बात पर विचार किया जाना चाहिए कि अगर उपयोगकर्ता फायरिंग प्रोग्राम को दुर्घटनाग्रस्त कर देता है तो उपयोगकर्ता कितना काम खो देगा। यह तब परेशान होता है जब ब्राउज़र खुले टैब का सेट खो देता है, लेकिन आम तौर पर आपदा नहीं; यह एक आपदा है यदि एक शब्द प्रोसेसर एक दावा के कारण एक दिन का काम खो देता है। कठिन भाग (ए) काम कर रहे हैं कि यह कुछ भी करने के लिए सुरक्षित है, और (बी) सिस्टम को ऐसे राज्य में रखते हुए जहां कुछ गलत हो जाता है, उसे पुनर्प्राप्त किया जा सकता है। –

+0

वह जो अपना काम सहेजने के बिना पूरे दिन जाता है, वह तब होता है जब वह एक जोर देता है। –

उत्तर

10

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

उपयोग दावे एक आंतरिक दोष प्रोग्रामिंग त्रुटियों, की स्थिति है कि घटित नहीं चाहिए, उदा तरह से संकेत मिलता है वर्ग/विधि आविष्कार और अमान्य प्रोग्राम स्थिति।

2

आप सभी की स्थिति है कि ऐसा कभी नहीं करना चाहिए की जांच करने के ज़ोर उपयोग करना चाहिए: इनपुट पर

  • पूर्व शर्त पैरामीटर वस्तु राज्य

पर

  • Postconditions मध्यवर्ती गणना की
  • परिणाम लेकिन आपको चाहिए केवल उन डीबग बिल्डों में या उन रिलीज के लिए स्पष्ट रूप से सक्रिय होने पर उन आवेदकों को शामिल करें (ग्राहकों को जारी किए गए निर्माण में नहीं)।

  • +1

    यदि खराब पूर्व शर्त आदि कोड से * पूरी तरह से * आपके नियंत्रण में हैं, तो दावा करने में विफल होने से ठीक है। लेकिन इन तरह की स्थितियों के बारे में क्या: गायब/गलत डीएलएस, गलत रजिस्ट्री प्रविष्टियां इत्यादि। – seand

    2

    मैं उपयोग के लिए जाँच करने के लिए किसी भी अवांछित कार्यक्रम राज्य का दावा है:

    • समारोह पूर्व शर्त
    • कभी कभी मैं उन्हें हर API कॉल के बाद एक मैक्रो में सम्मिलित करें: glDrawArray(); checkOpenGLError(); --checkOpenGLError() getGLError (कॉल करेंगे) अगर
    • पर डेटा संरचना अखंडता: जोर दें (कुछ == शून्य);
    • कभी-कभी जीडीबी मेरे पास है (आईओएस एसडीके 3.2)। मैं इसे साबित करने के लिए आवेषण का उपयोग करता हूं।

    संपादित करें:

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

    0

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

    संबंधित मुद्दे