कोड लिखने के चरण में त्रुटियों की संभावना को कैसे कम करें। नोट N4

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

परिचय

प्रारंभ में, पाठकों के लिए जानकारी जो मेरे पिछले नोटों से परिचित नहीं हैं। वे यहाँ पाए जा सकते हैं:

• नोट एन 1 [मिरांडा आईएम];
• नोट एन 2 [क्रोमियम, कैसल वोल्फेंस्टीन, आदि पर लौटें];
• नोट एन 3 [क्यूटी एसडीके]।

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

त्रुटि उदाहरण

उदाहरण N १। दोषपूर्ण तालिका अखंडता की जांच

  int AffixMgr :: parse_convtable (..., const char * कीवर्ड)
 {
   ...
   अगर (strncmp (टुकड़ा, कीवर्ड, आकार (कीवर्ड))! = 0) {
       HUNSPELL_WARNING (stderr,
                        "त्रुटि: लाइन% d: तालिका भ्रष्ट \ n है",
                        af-> getlinenum ());
       हटाएं * आरएल;
       * आरएल = NULL;
       वापसी 1;
   }
   ...
 } 

पीवीएस-स्टूडियो डायग्नॉस्टिक्स: वी 579 स्ट्रेंकैंप फ़ंक्शन तर्क और इसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। तीसरे तर्क का निरीक्षण करें। affixmgr.cpp 3708

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

उदाहरण 2. किसी फ़ाइल को पढ़ते समय निष्क्रिय जाँच

  int PatchFile :: LoadSourceFile (फ़ाइल का ढेर)
 {
   ...
   size_t c = fread (rb, 1, r, ofile);
   अगर (c <0) {
     लॉग करें ("लोडसोर्स फ़ाइल:"
          "गंतव्य फ़ाइल पढ़ने में त्रुटि:" LOG_S "\ n",
          mFile));
     वापसी READ_ERROR;
   }
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V547 एक्सप्रेशन 'c <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। updater.cpp 1179

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

  size_t फ़्रेड ( 
    शून्य * बफर,
    size_t आकार,
    size_t गिनती,
    फ़ाइल * स्ट्रीम 
 ); 

स्वाभाविक रूप से, परिणाम को संग्रहीत करने के लिए type size_t के चर 'c' का उपयोग किया जाता है। परिणामस्वरूप, चेक परिणाम (c <0) हमेशा गलत होता है।

यह एक अच्छा उदाहरण है। पहली नज़र में ऐसा लगता है कि किसी प्रकार का सत्यापन है, लेकिन व्यवहार में यह पता चला है कि यह पूरी तरह से बेकार है।

एक समान त्रुटि अन्य स्थानों में देखी जा सकती है:

V547 एक्सप्रेशन 'c <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। updater.cpp 2373

V547 एक्सप्रेशन 'c <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Bspatch.cpp 107

उदाहरण 3. उपयोग करने के बाद NULL के लिए एक पॉइंटर की जाँच करना

  nsresult
 nsFrameSelection :: MoveCaret (...)
 {
   ...
   mShell-> FlushPendingNotifications (Flush_Layout);
   अगर (mShell) {
     वापसी NS_OK;
   }
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V595 'mShell' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 1107, 1109. nsselection.cpp 1107

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

सबसे अधिक संभावना है, यह कोड काम करता है, क्योंकि mShell पॉइंटर हमेशा गैर-NULL होता है। मैं यह दिखाने के लिए एक उदाहरण देता हूं कि बहुत सरल जांच में भी गलती करना संभव है। एक चेक है, लेकिन इसका कोई मतलब नहीं है।

उदाहरण 4. उपयोग करने के बाद NULL के लिए एक पॉइंटर की जाँच करना

  CompileStatus
 mjit :: कंपाइलर :: performCompilation (JITScript ** jitp)
 {
   ...
   JaegerSpew (JSpew_Scripts,
     "सफलतापूर्वक संकलित (कोड \"% p \ ") (आकार \"% u \ ") \ n",
     (* jitp) -> code.m_code.executableAddress (),
     अहस्ताक्षरित ((* jitp) -> code.m_size));

   अगर (* jitp)
       वापसी Compile_Abort;
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V595 '' jitp 'पॉइंटर को nullptr के खिलाफ सत्यापित करने से पहले उपयोग किया गया था। लाइनों की जाँच करें: 547, 549. संकलक। 547

वैसे, सत्यापन से पहले एक सूचक का उपयोग करना एक सामान्य गलती है। यह इस विषय पर एक और उदाहरण है।

उदाहरण 5. इनपुट मूल्यों का अपूर्ण सत्यापन

  PRBool
 nSStyleAnimation :: AddWeighted (...)
 {
   ...
   if (यूनिट [0] == eCSSUnit_Null || यूनिट [1] == eCSSUnit_Null ||
       यूनिट [0] == eCSSUnit_Null ||  इकाई [0] == eCSSUnit_URL) {
     वापसी PR_FALSE;
   }
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V501 समान उप-अभिव्यक्तियों की इकाई है [0] == eCSSUnit_Null 'बाईं ओर और दाईं ओर' || ऑपरेटर। nsstyleanimation.cpp 1767

ऐसा लगता है कि अभी 2 टाइपो हैं। यह कहना मुश्किल है कि कोड को यहाँ कैसे दिखना चाहिए, लेकिन मैं शायद इसे इस तरह लिखना चाहता था:

  if (यूनिट [0] == eCSSUnit_Null || यूनिट [1] == eCSSUnit_Null ||
     यूनिट [0] == eCSSUnit_URL ||  इकाई [1] == eCSSUnit_URL) { 

टाइपोस अमान्य इनपुट मानों को संसाधित करने के लिए फ़ंक्शन का कारण हो सकता है।

उदाहरण 6. इनपुट मूल्यों का अपूर्ण सत्यापन

  nsresult Preshell :: SetResolution (फ़्लोट aXResolution, फ़्लोट aYResolution)
 {
   अगर ((aXResolution> 0.0 && aXResolution> 0.0)) {
     NS_ERROR_ILLEGAL_VALUE;
   }
   ...
 } 

डायग्नोस्टिक्स PVS-Studio: V501 बाईं और 'और&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: aXResolution> 0.0 && aXResolution> 0.0 nspresshell.cpp 5114

और यहां इनपुट मापदंडों की असफल जांच का एक और उदाहरण है। इस बार, एक टाइपो के कारण, aYResolution तर्क के मूल्य की जाँच नहीं की जाती है।

उदाहरण 7. अपरिचित सूचक

  nsresult
 SVGNumberList :: SetValueFromString (const nsAString और aValue)
 {
   ...
   const char * token = str.get ();
   अगर (टोकन == '\ 0') {
     NS_ERROR_DOM_SYNTAX_ERR लौटें;  // कॉमा के बीच कुछ भी नहीं
   }
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V528 यह अजीब है कि 'char' प्रकार के पॉइंटर की तुलना '\ 0' मान से की जाती है। संभवतः इसका मतलब है: * टोकन == '\ 0'। svgnumberlist.cpp 96

यह जांचना कि अल्पविराम के बीच कुछ भी नहीं है काम नहीं करता है। यह जानने के लिए कि क्या एक खाली स्ट्रिंग है या नहीं, आप पहले वर्ण की तुलना '\ 0' से कर सकते हैं। लेकिन यहां, पहले चरित्र की तुलना शून्य से नहीं की जाती है, बल्कि सूचक की जाती है। यह पॉइंटर हमेशा गैर-शून्य होता है। सही जांच इस तरह दिखनी चाहिए: (* टोकन == '\ 0')।

उदाहरण 8. सूचकांक भंडारण के लिए अनुचित प्रकार

  PRBool 
 nsIEProfileMigrator :: TestForIE7 ()
 {
   ...
   PRUint32 सूचकांक = ieVersion.FindChar ('।', 0);
   यदि (सूचकांक <0)
     वापसी PR_FALSE;
   ...
 } 

PVS-Studio डायग्नोस्टिक्स: V547 एक्सप्रेशन 'इंडेक्स <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Nsieprofilemigrator.cpp 622

यदि पंक्ति में कोई डॉट नहीं है और फ़ंक्शन गलत डेटा के साथ काम करना जारी रखता है, तो फ़ंक्शन PR_FALSE को वापस नहीं करेगा। त्रुटि यह है कि चर 'सूचकांक' के लिए एक अहस्ताक्षरित डेटा प्रकार का चयन किया गया है। जाँच (इंडेक्स <0) का कोई मतलब नहीं है।

उदाहरण 9. गलत त्रुटि संदेश उत्पन्न करना

  cairo_status_t
 _cairo_win32_print_gdi_error (कास्ट चार * संदर्भ)
 {
   ...
   fwprintf (stderr, L "% s:% S", संदर्भ, (wchar_t *) lpMsgBuf);
   ...
 } 

डायग्नोस्टिक्स पीवीएस-स्टूडियो: वी 576 गलत प्रारूप। 'Fwprintf' फ़ंक्शन के तीसरे वास्तविक तर्क की जाँच करने पर विचार करें। Wchar_t प्रकार के प्रतीकों के स्ट्रिंग के लिए सूचक अपेक्षित है। कैरो-विन32-सरफेस। 129

यहां तक ​​कि अगर त्रुटि का सफलतापूर्वक पता चला है, तो भी इसे ठीक से संभालने में सक्षम होने की आवश्यकता है। और चूंकि कोई भी त्रुटि संचालकों का परीक्षण नहीं कर रहा है, आप वहां बहुत सारी दिलचस्प चीजें देख सकते हैं।

_Cairo_win32_print_gdi_error () फ़ंक्शन जिबरिश प्रिंट करेगा। तीसरे तर्क के रूप में, fwprintf () फ़ंक्शन एक संकेतक को एक यूनिकोड स्ट्रिंग की अपेक्षा करता है, और इसके बजाय प्रारूप में एक स्ट्रिंग प्राप्त करता है 'const char *'।

उदाहरण 10. त्रुटि लेखन डंप

  बूल एक्सेप्शनहैंडलर :: WriteMinidumpForChild (...)
 {
   ...
   DWORD last_suspend_cnt = -1;
   ...
   // यह धागा पहले ही मर चुका होगा, इसलिए नहीं खुल रहा है
   // हैंडल एक गैर-घातक त्रुटि है
   अगर (NULL! = child_thread_handle) {
     if (0 <= (last_suspend_cnt =)
                 SuspendThread (child_thread_handle))) {
   ...
 } 

पीवीएस-स्टूडियो डायग्नोस्टिक्स: वी 547 एक्सप्रेशन हमेशा सच होता है। अहस्ताक्षरित प्रकार का मान हमेशा> = 0. अपवाद_हैंडलर .cc 846 है

यह एक त्रुटि हैंडलर में एक और उदाहरण है। SuspendThread फ़ंक्शन द्वारा लौटाया गया परिणाम यहां सही ढंग से संसाधित नहीं हुआ है। चर last_suspend_cnt DWORD प्रकार का है, जिसका अर्थ है कि यह हमेशा 0 से अधिक या बराबर होगा।

फ़ायरफ़ॉक्स में अन्य त्रुटियां

मैं एक छोटा सा विषयांतर करूँगा और संपूर्ण रूप से फ़ायरफ़ॉक्स चेक के परिणामों के बारे में बताऊंगा। परियोजना उच्च गुणवत्ता की है, और पीवीएस-स्टूडियो ने कुछ त्रुटियों का खुलासा किया। हालांकि, चूंकि यह बड़ा है, इसलिए मात्रात्मक रूप से काफी त्रुटियां हैं। दुर्भाग्य से, मैं पीवीएस-स्टूडियो टूल द्वारा जारी रिपोर्ट की पूरी तरह से जांच करने में सक्षम नहीं था। तथ्य यह है कि फ़ायरफ़ॉक्स के लिए विजुअल स्टूडियो के लिए कोई प्रोजेक्ट फ़ाइल नहीं है। प्रोजेक्ट को PVS-Studio के कंसोल संस्करण द्वारा चेक किया गया था, जिसे मेक-फाइल से बुलाया गया था। विजुअल स्टूडियो में रिपोर्ट खोलकर, आप सभी नैदानिक ​​संदेश देख सकते हैं। लेकिन जब से कोई परियोजना नहीं है, तब विज़ुअल स्टूडियो सुझाव नहीं देता है कि कौन से चर घोषित किए जाते हैं, आपको मैक्रोज़ परिभाषित किए गए स्थान पर जाने की अनुमति नहीं देता है, और इसी तरह। नतीजतन, एक अज्ञात परियोजना का विश्लेषण अत्यंत समय लेने वाला है, और मैं संदेशों के केवल भाग का अध्ययन करने में सक्षम था।

त्रुटियाँ विविध हैं। उदाहरण के लिए, सरणी की सीमाओं से परे एक निकास है:

  वर्ग nBBaseStatis: सार्वजनिक nsStatis {
 सार्वजनिक:
   ...
   PRUint32 mLWordLen [10]; 
   ...
   nsBaseStatis :: nsBaseStatis (...)
   {
     ...
     के लिए (PRUint32 i = 0; मैं <20; मैं ++)
        mLWordLen [i] = 0;
     ...
   }
   ...
 }; 

डायग्नोस्टिक्स पीवीएस-स्टूडियो: वी 557 ऐरे ओवररन संभव है। 'I' इंडेक्स का मान 19 तक पहुंच सकता है। Detcharset.cpp 89

यद्यपि यह और इसी तरह की त्रुटियां दिलचस्प हैं, वे इस लेख के विषय से संबंधित नहीं हैं। इसलिए, यदि रुचि है, तो आप इस फ़ाइल में कुछ अन्य त्रुटियों को देख सकते हैं: mozilla-test.txt ।

त्रुटि हैंडलर में त्रुटियों पर वापस

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

इसके बारे में क्या करना है और क्या सिफारिशें की जा सकती हैं?

पहली सिफारिश

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

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

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

इसलिए अब आपको चेतावनी दी गई है। और मुझे यकीन है कि यह पहले से ही बहुत अच्छा और उपयोगी है।

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

दूसरी सिफारिश

डंप भंडारण तंत्र, लॉगिंग फ़ंक्शन और अन्य समान सहायक तंत्र उनके लिए इकाई परीक्षण किए जाने के लायक हैं।

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

सिफारिश सरल और स्पष्ट लगती है। लेकिन इस नोट को पढ़ने वालों में से कितने के पास WriteMyDump वर्ग का परीक्षण करने के लिए इकाई परीक्षण हैं?

तीसरी सिफारिश

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

दूसरे शब्दों में, स्थिर विश्लेषण में, कोड कवरेज 100% है। अन्य प्रकार के परीक्षण का उपयोग करके कोड के ऐसे कवरेज को प्राप्त करना लगभग असंभव है। यूनिट परीक्षणों और प्रतिगमन परीक्षण के लिए कोड कवरेज आमतौर पर 80% से कम है। शेष 20% परीक्षण करना बहुत कठिन है। इन 20% में अधिकांश त्रुटि हैंडलर और दुर्लभ परिस्थितियां शामिल हैं।

चौथी सिफारिश

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

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

निष्कर्ष

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