🌮 💆 🐱 अपवाद क्रैश ⛺️ 🧗🏿 🎟️

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

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

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

रेमंड चेन ने 2004 में इस समस्या का वर्णन किया:

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

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

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

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

def spawn(argv, master_read=_read, stdin_read=_read): """Create a spawned process.""" if type(argv) == type(''): argv = (argv,) pid, master_fd = fork() if pid == CHILD: os.execlp(argv[0], *argv) (...)

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

यहाँ एक और दिलचस्प उदाहरण है:

 $ make clean Sorry, command-not-found has crashed! Please file a bug report at: https://bugs.launchpad.net/command-not-found/+filebug Please include the following information with the report: command-not-found version: 0.3 Python version: 3.2.3 final 0 Distributor ID: Ubuntu Description: Ubuntu 13.04 Release: 13.04 Codename: raring Exception information: unsupported locale setting Traceback (most recent call last): File "/.../CommandNotFound/util.py", line 24, in crash_guard callback() File "/usr/lib/command-not-found", line 69, in main enable_i18n() File "/usr/lib/command-not-found", line 40, in enable_i18n locale.setlocale(locale.LC_ALL, '') File "/usr/lib/python3.2/locale.py", line 541, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting

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

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

 try: locale.setlocale(locale.LC_ALL, '') except Exception as e: print("Cannot change locale:", e)

जाहिर है, यह करना आसान है। लेकिन, फिर से, समस्या यह है कि यह अभी नहीं करना स्वाभाविक था। वास्तव में, यह प्राकृतिक से अधिक है: यह वास्तव में बेहतर लगता है कि गलत मार्ग पर विचार न करें। इस मामले में, कोड छोटा हो जाएगा, यह अधिक सीधा होगा, और इसके परिणामस्वरूप, केवल एक ही वांछित सामग्री की ओर जाता है।

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

दुर्घटना और बस अप्रत्याशित व्यवहार की एक अद्भुत राशि ऐसी अनैच्छिक लापरवाही का परिणाम है।

मूल

अपवाद क्रैश

More articles: