रिटर्न कोड बनाम अपवाद: बेल्फ़्री से एक दृश्य

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

फोरचेक के बारे में बात करना बंद करो। मैं उदाहरण के तौर पर सीधे दो संचालकों को एक-दूसरे के समान दिखाऊंगा, जिनमें से एक कार्यान्वयन के रूप में "अपवाद" का उपयोग करता है, दूसरा "रिटर्न कोड" का उपयोग करता है।

प्रक्रिया-अपवाद [ मानचित्रण और निकाय ]
, जहां मैपिंग फॉर्म का एक नक्शा है {अपवाद 1 <-> प्रसंस्करण विधि 1, अपवाद 2 <-> प्रसंस्करण विधि 2, ...}, ऑपरेटर का शरीर - जिसमें अपवाद हो सकता है।

और दूसरा ऑपरेटर:
प्रक्रिया-रेटकोड-उत्तर [ मानचित्रण और निकाय ]
, जहां मैपिंग फॉर्म का एक मैप है {रिटर्न कोड 1 <-> प्रोसेसिंग विधि 1, रिटर्न कोड 2 <-> प्रोसेसिंग विधि 2, ...}, बॉडी - स्टेटमेंट जो सबप्रोग्राम या किसी भी तथाकथित प्रणाली की प्रतिक्रिया के साथ समाप्त होता है जिसे होना चाहिए रिटर्न कोड के आधार पर प्रक्रिया।

आइए देखते हैं वे काम करते हैं।

प्रक्रिया-retcode-जवाब

मान लें कि हमारे पास रिटर्न कोड 0, -1, -2 को संसाधित करने और शेष कोडों को संसाधित करने के लिए तर्क हैं:

( defn ok-processor [ परिणाम ]
( Println ( str "ok। परिणाम:" परिणाम ) ) )

( चूक त्रुटि प्रोसेसर [ परिणाम ]
( println ( str "error। परिणाम:" परिणाम ) ) )

( दूसरे त्रुटि-प्रोसेसर को बदनाम करना [ परिणाम ]
( Println ( str "एक और त्रुटि। परिणाम:" परिणाम ) ) )

( defn अज्ञात-त्रुटि-प्रोसेसर [ परिणाम ]
( Println ( अज्ञात "अज्ञात त्रुटि। परिणाम:" परिणाम ) ) )

हम उन कार्यों के नामों के लिए मानचित्र रिटर्न कोड परिभाषित करते हैं जो उन्हें संसाधित करते हैं:

( डिफ रिजल्ट-मैपिंग { 0 ’ओके-प्रोसेसर
- 1 'त्रुटि-प्रोसेसर
- 2 'अन्य त्रुटि-प्रोसेसर
: अन्य 'अज्ञात-त्रुटि-प्रोसेसर } )

अब टेस्ट रूटीन बनाएं जो अलग-अलग रिटर्न कोड और संबंधित परिणाम देते हैं:

( defn test-call-ok [ ]
[ 0 "परीक्षा परिणाम" ] )

( defn test-call- error [ ]
[ - 1 "परीक्षा परिणाम" ] )

( चूक-परीक्षण-कॉल-अन्य- त्रुटि [ ]
[ - 2 "परीक्षा परिणाम" ] )

( चूक परीक्षण-कॉल-अज्ञात- त्रुटि [ ]
[ - 1000 "परीक्षा परिणाम" ] )

इस मामले में हमारे ऑपरेटर का काम इस तरह दिखता है:

( प्रक्रिया-रेटकोड-उत्तर परिणाम-मानचित्रण ( परीक्षण-कॉल-ओके ) )
ठीक। परिणाम : परीक्षा परिणाम

( प्रक्रिया-रेटकोड-उत्तर परिणाम-मानचित्रण ( परीक्षण-कॉल- त्रुटि ) )
त्रुटि । परिणाम : परीक्षा परिणाम

( प्रक्रिया-रेटकोड-उत्तर परिणाम-मानचित्रण ( परीक्षण-कॉल-अन्य- त्रुटि ) )
एक और त्रुटि । परिणाम : परीक्षा परिणाम

( प्रक्रिया-रेटकोड-उत्तर परिणाम-मानचित्रण ( परीक्षण-कॉल-अज्ञात- त्रुटि ) )
अज्ञात त्रुटि । परिणाम : परीक्षा परिणाम

यहाँ, प्रत्येक शरीर में केवल एक ही विधि समाहित है। वास्तविकता में, आप इसके बजाय किसी भी क्रम को सम्मिलित कर सकते हैं।

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

कोई इफ नहीं। यह दृष्टिकोण रिटर्न कोड के प्रसंस्करण के लिए एक काफी लचीले पैटर्न को लागू करता है।

प्रक्रिया-अपवाद

पिछले उदाहरण के साथ सादृश्य द्वारा। कुछ अपवादों से निपटने के लिए कार्य हैं:

( डिफेंस एरिथमैटिक-अपवाद-प्रोसेसर [ e ]
( Println ( "अंकगणित अपवाद" ) ) )

( nnppointer- अपवाद-प्रोसेसर [ ईएन ]
( Println ( str "Nullpointer अपवाद।" ) ) )

( एक और अपवाद-प्रोसेसर को बदनाम करना [ e ]
( Println ( str "अन्य अपवाद।" ) ) )

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

( def अपवाद-मैपिंग { java । lang । ArithmeticException 'अंकगणित-अपवाद-प्रोसेसर)
जावा लंग । NullPointerException 'nullpointer-अपवाद-प्रोसेसर
जावा लंग । अपवाद 'अन्य-अपवाद-प्रोसेसर } )

हम परीक्षण दिनचर्या बनाते हैं जो विभिन्न अपवाद उत्पन्न करते हैं:

( defn test-call-ok [ ]
"परीक्षा परिणाम" )

( परीक्षण-फेंक-अंकगणित-अपवाद [ ]
( थ्रो ( नया जावा । लैंग । अरिथमेटिक एक्ससेप्शन ) )
"परीक्षण फिर से आना" )

( defn test-throw-nullpointer- अपवाद [ ]
( फेंक ( नया जावा । लंग । NullPointerException ) )
"परीक्षण फिर से आना" )

( परीक्षण-फेंक-अन्य-अपवाद [ ]
( फेंक ( नया जावा । लैंग । ClassNotFoundException ) )
"परीक्षण फिर से आना" )

हमारे ऑपरेटर का काम:

( प्रक्रिया-अपवाद अपवाद-मानचित्रण
( परीक्षण-कॉल-ओके ) )
"परीक्षा परिणाम"

( प्रक्रिया-अपवाद अपवाद-मानचित्रण
( परीक्षण-फेंक-अंकगणित-अपवाद ) )
अंकगणित अपवाद ।

( प्रक्रिया-अपवाद अपवाद-मानचित्रण
( परीक्षण-थ्रो-नलपॉइंट-अपवाद ) )
Nullpointer अपवाद ।

( प्रक्रिया-अपवाद अपवाद-मानचित्रण
( परीक्षण-फेंक-अन्य-अपवाद ) )
अन्य अपवाद ।

पिछले बयान के विवरण के अंत में टिप्पणी यहां लागू होती है।

निष्कर्ष

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

यहाँ उपरोक्त ऑपरेटरों के लिए एक कार्यान्वयन विकल्प है:

( डिफमैक्रो प्रोसेस-अपवाद [ मानचित्रण और निकाय ]
( let [ कैच-आइटम] ( नक्शा ( fn [ m ])
` ( कैच ~ ( पहला मी ) ई #
( ~ ( eval ( दूसरा m ) ) e # ) ) )
( eval मानचित्रण ) ) ]
` ( कोशिश ~ @ शरीर
~ @ पकड़-आइटम ) ) )

( डिफमैक्रो प्रोसेस-रेटकोड-उत्तर [ मैपिंग एंड बॉडी ]
` ( चलो [ जवाब # ( ~ ~ शरीर )
रेटकोड # ( पहला उत्तर # )
परिणाम # ( दूसरा उत्तर # )
प्रोसेसर # ( गेट ~ मैपिंग रेटकोड # )
प्रोसेसर # ( अगर ( शून्य; प्रोसेसर # ) : ( अन्य ~ मैपिंग ) प्रोसेसर # ) ]
( ( eval processor # ) परिणाम # ) ) )

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