अपवाद हैंडलिंग में विकल्प बनाम अपवाद

Question

कुछ समय के लिए F # option का उपयोग करने के बाद, मुझे एहसास हुआ कि इसका उपयोग असाधारण मामलों को संभालने के लिए किया जा सकता है। सूची से

1. find कार्य/सरणी/Seq मॉड्यूल असामान्य मामलों में KeyNotFoundException बढ़ा है, जबकि इसी tryFind समकक्षों उन स्थितियों में None वापसी: मैं निम्न उदाहरण में या तो option या Exception उपयोग कर सकते हैं।
2. जब मैं बैकट्रैकिंग (एन-क्वींस, सुडोकू इत्यादि को हल करने में) करता हूं, जब भी किसी शाखा में कोई समाधान नहीं होता है, तो मैं या तो अपवाद उठा सकता हूं और इसे बाद में पकड़ सकता हूं या बैकट्रैक पर उस मान से मेल खाने के लिए कोई भी नहीं लौटा सकता हूं। जब तक हम समाधान नहीं पाते हैं तब तक वे मामले अक्सर होते हैं। जबकि Exception अधिक नेट मंच में सामान्य रूप से प्रयुक्त है

मेरे छाप option है, एक और अधिक कार्यात्मक दृष्टिकोण है।

उपयोगिता, प्रदर्शन इत्यादि के मामले में अपवाद प्रबंधन में option और Exception के बीच अंतर क्या हैं? एक तकनीक का उपयोग करने वाले मामलों में दूसरे का उपयोग करने से बेहतर है?

Answer 1

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

क्योंकि यह सीएलआर की एक संपत्ति है, इससे कोई फर्क नहीं पड़ता कि आप एफ # में हैं या नहीं। मेरी समझ यह है कि एमएल जैसी भाषाओं के लिए अन्य रनटाइम, उदा। ocaml, इस विशेषता नहीं है, और इसलिए नियंत्रण प्रवाह के लिए अक्सर अपवाद का उपयोग कर सकते हैं।

Answer 2

सैद्धांतिक दृष्टिकोण से। option ऐसा कुछ है जो आपको उन कार्यों में उपयोग करना चाहिए जो एफपी बिंदु से शुद्ध हैं (आप शुद्ध कार्यों के बारे में Google कर सकते हैं)। अपरिपक्व दुनिया के बारे में अपवाद हैं (हास्केल में आईओ दुनिया की तरह)।

अब व्यावहारिक रूप से दृष्टिकोण से मैं option का उपयोग रिटर्न प्रकार के रूप में करने का सुझाव दूंगा जब आपके आवेदन का तर्क कहता है कि मूल्य वहां हो सकता है या यह नहीं हो सकता है। यानी मूल्य मौजूद नहीं है, यह वैध आवेदन नियम है। अपवाद कुछ ऐसा होता है जिसे आवेदन तर्क में कुछ होता है जो गलत तर्क निष्पादन या कुछ गलत अनुप्रयोग स्थिति को इंगित करता है जिसे अनुप्रयोग नियमों के अनुसार अपेक्षित नहीं किया गया था।

प्रदर्शन से पीओवी फेंकने का अपवाद अधिक महंगा है (अवांछित ढेर के कारण - उपयुक्त अपवाद हैंडलर आदि की तलाश में) विकल्प विकल्प प्रकार की तुलना में।

Answer 3

प्रयोज्यता के मामले में मैं एफ # में विकल्प पसंद करता हूं।

• विकल्प असाधारण राज्य के साथ-साथ अपेक्षित राज्य को समाहित करते हैं। यह आपको असाधारण स्थिति को संभालने की अनुमति देता है जब तक आपको अपेक्षित स्थिति की आवश्यकता न हो।
• विकल्प में helper functions भी हैं, आपको अपवादों के साथ खुद को लिखना होगा।
• Partial Active Patterns आपको कई असाधारण मामलों को विकल्पों के साथ बहुत साफ तरीके से संभालने की अनुमति देता है।
• Optional Paramaters एफ # में विकल्प के साथ लागू किया गया है। उपरोक्त वर्णित यह स्थगित प्रकृति आपको असाधारण मामले उत्पन्न करने की परवाह नहीं करती है, जब तक कि उपभोक्ता के पास इसके लिए डिफ़ॉल्ट मान न हो।

विकल्प असाधारण मामलों के बारे में सोचने का मूल रूप से अलग तरीका हैं और मुझे विश्वास है कि एफ # विशेष बनाने में मदद करें।

Answer 4

मेरा प्रश्न उपयोगिता, प्रदर्शन ... के मामले में अपवाद हैंडलिंग में विकल्प और अपवाद के बीच अंतर क्या है?

option प्रकार अपवादों की तुलना में मजबूत स्थिर जांच प्रदान करता है, जिससे प्रोग्रामर त्रुटि को संकलक द्वारा पकड़ा जाएगा। गैर-असाधारण रूप से लौटने की संभावना Some परिणाम लौटने से तेज होने की संभावना है लेकिन None लौटने से सैकड़ों बार धीमा हो रहा है।

किस मामले में तकनीक का उपयोग दूसरे से बेहतर है?

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