ज़ोर। यह क्या है

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

मुखर को निम्नलिखित वर्गों में विभाजित किया जा सकता है:

• फ़ंक्शन की शुरुआत में इनपुट तर्कों की जाँच करना।

यदि किसी तर्क के लिए एक अमान्य मूल्य पाया जाता है, तो कहीं उस स्थान के पास जहां यह फ़ंक्शन कहा जाता था, वहां कीड़े हो सकते हैं। एक उदाहरण:

//    n. //  n      0  10 . int factorial(int n) { //      assert(n >= 0); //  n  10,        //  ,    . assert(n <= 10); if (n < 2) { return 1; } return factorial(n - 1) * n; } //  ''    factorial()    //    0  99. // //   factorial()      , //          . // //     ,       // ,         //   . for (int i = 0; i < 100; ++i) { a[i] = factorial(i); } 

पूर्णांक अतिप्रवाह क्या है।
स्टैक ओवरफ्लो क्या है।

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

 int factorial(int n) { int result = 1; for (int i = 2; i <= n; ++i) { result *= i; } //         -   //    .    n   // ,   .    // a[i]      . // //          , //      n,    //    . assert(result > 0); return result; } 

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

• फ़ंक्शन कोड के अंदर काम करने वाले डेटा की जांच करना।

यदि किसी फ़ंक्शन के बीच में गलत डेटा का पता लगाया जाता है, तो इस चेक के क्षेत्र में कीड़े हो सकते हैं। एक उदाहरण:

 int factorial(int n) { int result = 1; while (n > 1) { //      . // //      ,      //     n,   . // //   ,      (  //  ), ..      result, //         ,  //    (  )   // result  . assert(result <= INT_MAX / n); result *= n; --n; } return result; } 

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

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

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

 //   . // //  0,      -  : // -    . // - mtx     . //  1,    . int acquire_mutex(mutex *mtx); //   . // //  0,      -  // : // -    . // - mtx     . //  1,    . int release_mutes(mutex *mtx); // ,   . assert(acquire_mutex(mtx)); //   , "" . process_data(data_protected_by_mtx); // ,   . assert(release_mutes(mtx)); 

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

 int is_success; is_success = acquire_mutex(mtx); assert(is_success); //        assert'. process_data(data_protected_by_mtx); is_success = release_mutex(mtx); assert(is_success); 

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

 //   buf_size  ,    buf, //     connection. // //  0    ,     . , //       . //  1     . int write(connection *connection, const void *buf, size_t buf_size); int is_success = write(connection, buf, buf_size); // "",    . assert(is_success); 

यदि लिखना () रिटर्न 0 है, तो इसका मतलब यह नहीं है कि हमारे कार्यक्रम में कोई बग है। यदि कार्यक्रम में जोर दिया जाता है, तो लेखन त्रुटि पर ध्यान नहीं दिया जा सकता है, जो बाद में दु: खद परिणाम दे सकता है। इसलिए, मुखर () यहां फिट नहीं है। सामान्य त्रुटि हैंडलिंग यहां बेहतर अनुकूल है। उदाहरण के लिए:

 while (!write(connection, buf, buf_size)) { //          . close_connection(connection); connection = create_connection(); } 

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

 function assert(condition) { if (!condition) { throw "Assertion failed! See stack trace for details"; } } assert(2 + 2 === 4); assert(2 + 2 === 5); 

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