उदाहरण होना चाहिए - यहां तक ​​कि शुरुआती उदाहरण - त्रुटि-हैंडलिंग कोड शामिल करें?

Question

ब्रायन कर्निघन को इस प्रश्न को recent interview में पूछा गया था। मैं उसका जवाब उद्धृत करूंगा:

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

कोड कोड को प्रदर्शित करते समय कोड को अव्यवस्थित करने के सवाल से परे, मुझे लगता है कि प्रश्न बन जाता है, कैसे क्या आप अपने उदाहरण कोड में त्रुटि को संभालने का विकल्प चुनते हैं?

यही कहना है, आप क्या करते हैं? एक आवेदन के लिए घातक क्या है किसी और के लिए घातक नहीं है। जैसे अगर मैं किसी वेबसर्वर से कुछ जानकारी प्राप्त नहीं कर सकता (चाहे वह 404 त्रुटि हो या एक गैर-उत्तरदायी सर्वर हो) जो घातक हो सकता है यदि आप उस डेटा के बिना कुछ भी नहीं कर सकते हैं। लेकिन यदि वह डेटा आप जो कर रहे हैं उसके लिए पूरक है, तो शायद आप इसके बिना जी सकते हैं।

तो उपर्युक्त त्रुटि को लॉगिंग करने के लिए इंगित कर सकता है। त्रुटि पूरी तरह से अनदेखा करने से बेहतर है। लेकिन मुझे लगता है कि अक्सर कठिनाई होती है कि किसी त्रुटि से कैसे/कब (और कब नहीं) को पुनर्प्राप्त करना है। शायद यह खुद में एक नया ट्यूटोरियल है।

Answer 6

मुझे लगता है कि समाधान बीच में कहीं है।

function a(x,y) 
{ 
    assert(isvalid(x)) 
    assert(isvalid(y)) 
    logic() 
} 

क्या एक इनपुट वैध बनाता है के बारे में स्पष्ट होना करने के लिए, बस उस पाठक को पता होना चाहिए की कोई जरूरत नहीं है: आप सूची 'y' में तत्व 'एक्स' को खोजने के लिए एक समारोह को परिभाषित कर रहे हैं, तो आप कुछ इस तरह करते हैं कि तर्क मान्य इनपुट मानता है।

DONT_FORGET_TO_ADD_ERROR_CHECKING(); // You have been warned! 

सभी इस करता कोड "बल्लेबाजी बंद" संकलन किसी के लिए रोकने के है, जो बस आँख बंद करके प्रतियां और:

Answer 7

एक विचार मैं अपने उदाहरण कोड में निम्नलिखित कहीं तरह की एक पंक्ति शामिल करने के लिए किया जाएगा था इसे चिपकाता है (क्योंकि स्पष्ट रूप से DONT_FORGET_TO_ADD_ERROR_CHECKING() कहीं भी परिभाषित नहीं किया गया है)। लेकिन यह भी एक परेशानी है, और शायद कठोर समझा जा सकता है।

Answer 8

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

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

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

Answer 9

एक दृष्टिकोण मैंने देखा है, विशेष रूप से Advanced Programming in the UNIX Environment और UNIX Network Programming त्रुटि जांच कोड के साथ कॉल लपेटना है और फिर उदाहरण कोड में रैपर का उपयोग करना है। उदाहरण के लिए:

ssiz_t Recv(...) 
{ 
    ssize_t result; 
    result = recv(...); 
    /* error checking in full */ 
} 

तो, बुला कोड में:

Recv(...); 

इस तरह आप त्रुटि हैंडलिंग को दिखाने के लिए है, जबकि कोड बुला स्पष्ट और संक्षिप्त होने के लिए के प्रवाह की अनुमति के मिलता है।

Answer 10

उदाहरण उदाहरण होना चाहिए। उन्हें हमेशा जितना संभव हो उतना कम व्याकुलता के साथ स्पष्ट रूप से बिंदु को दिखाया जाना चाहिए। यहां मेटा-उदाहरण दिया गया है:

कहें कि हम एक फ़ाइल से एक संख्या पढ़ना चाहते हैं, 3 जोड़ें, और इसे कंसोल पर प्रिंट करें। हमें कुछ चीजों को प्रदर्शित करने की आवश्यकता होगी।

infile = file("example.txt") 
content = infile.read() 
infile.close() 
num = int(content) 
print (3 + num) 

शब्दकोष, लेकिन सही, सिवाय कुछ ऐसी चीजें हैं जो गलत हो सकती हैं। सबसे पहले, अगर फ़ाइल मौजूद नहीं है तो क्या होगा? क्या होगा यदि यह अस्तित्व में है लेकिन इसमें कोई संख्या नहीं है?

तो हम दिखाते हैं कि त्रुटियों को कैसे संभाला जाएगा।

try: 
    infile = file("example.txt") 
    content = infile.read() 
    infile.close() 
    num = int(content) 
    print (3 + num) 
except ValueError: 
    print "Oops, the file didn't have a number." 
except IOError: 
    print "Oops, couldn't open the file for some reason." 

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

पहले अनियंत्रित अतिरिक्त चर को खत्म करने देता है।

infile = file("example.txt") 
print (3 + int(infile.read())) 
infile.close() 

जब से हम यह करने के लिए लिख नहीं कर रहे हैं, न ही यह एक लंबी चलने वाली प्रक्रिया पर एक महंगी संसाधन है, यह इसके खुला छोड़ने के लिए वास्तव में सुरक्षित है। कार्यक्रम समाप्त होने पर यह बंद हो जाएगा।

print (3 + int(file("example.txt").read())) 

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

with file("example.txt") as infile: 
    print (3 + int(infile.read())) 

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

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

Answer 11

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

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

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

public void DoSomethingCool() 
{ 
    try 
    { 
     // do something cool 
    } 
    catch (Exception ex) 
    { 
     throw ex; 
    } 
} 

मैं प्राप्त हो गया है सैकड़ों इस तरह की हर विधि। मैंने फेंकने वाले लोगों के लिए बोनस अंक देना शुरू कर दिया है; पूर्व फेंकने के बजाय;

Answer 12

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

अगर यह इंगित करता है कि त्रुटि प्रबंधन को जोड़ने की आवश्यकता है। देवता के प्यार के लिए यह भी इंगित करता है कि किन त्रुटियों को संभालने की आवश्यकता है।

यह कुछ उदाहरण पढ़ने का सबसे निराशाजनक हिस्सा है। यदि आप नहीं जानते कि आप क्या कर रहे हैं (जिसे हमें उदाहरण के पाठक को मानना ​​है ...) आप नहीं जानते कि किन त्रुटियों को देखना है। जो "जोड़ त्रुटि प्रबंधन" सुझाव को बदलता है "यह उदाहरण बेकार है"।

Answer 13

नमूना कोड में त्रुटि प्रबंधन शामिल नहीं है, लेकिन इसे अन्यथा उचित सुरक्षित कोडिंग तकनीक का प्रदर्शन करना चाहिए। कई वेब कोड स्निपेट OWASP शीर्ष दस का उल्लंघन करते हैं।