मैंने इस बारे में पढ़ा है कि एरलांग जैसी भाषाओं में प्रोग्रामिंग की विफल-तेज शैली कैसे अधिकांश अन्य भाषाओं में रक्षात्मक शैली की तुलना में बहुत कम कार्यक्रमों के साथ समाप्त होती है। क्या यह सभी प्रकार के कार्यक्रमों के लिए सही है और इसके लिए तर्क क्या है?रक्षात्मक शैली कार्यक्रमों की तुलना में असफल फास्ट स्टाइल प्रोग्राम क्यों कम हैं?
विफल-फास्ट प्रोग्राम रक्षात्मक शैली कार्यक्रमों से जरूरी नहीं हैं: यह आपके रक्षात्मक कोड को सुरक्षित करने के लिए आवश्यक कार्यान्वयन और उपायों पर निर्भर करता है।
एरलांग के मामले में, विफल-गति कार्यक्रम आम तौर पर घोषणात्मक शैली के कारण कम होते हैं और वीएम आपके लिए त्रुटि मामलों को उत्पन्न करने के लिए कैसे सुनिश्चित करता है।
day(1) -> sunday;
day(2) -> monday;
day(3) -> tuesday;
day(4) -> wednesday;
day(5) -> thursday;
day(6) -> friday;
day(7) -> saturday;
किसी भी अप्रत्याशित मूल्य समारोह के लिए पारित एक त्रुटि है कि पकड़ा और एक अन्य प्रक्रिया (यानी .: एक पर्यवेक्षक) द्वारा नियंत्रित किया जा सकता है में परिणाम होगा: एक उदाहरण है, समारोह में के रूप में। ऐसी त्रुटियां पूरी तरह से सिस्टम को कभी भी खतरे में नहीं डालती हैं और फ़ंक्शन में कोड जोड़ने की आवश्यकता नहीं होती है - यह सब पूर्व निर्धारित व्यवहार द्वारा सामान्य निष्पादन पथ के बाहर किया जाता है।
एक गतिशील भाषा में जहां असफलता मानक नहीं है, आपको सीमाओं को मैन्युअल रूप से जांचना होगा और स्वयं को अपवाद फेंकना होगा। फिर आपको स्थानीय रूप से अपवाद को पकड़ना होगा (शीर्ष-स्तरीय प्रयास ... कैच शामिल हैं) यदि आप पूरी प्रणाली को नीचे नहीं जाना चाहते हैं। त्रुटि प्रबंधन कोड आमतौर पर सामान्य निष्पादन पथ में डालना पड़ता है।
एक स्थिर भाषा में जहां असफलता मानक नहीं है, तो आपका कोड कितना समय होगा आपके सिस्टम प्रकार पर निर्भर करेगा। यदि भाषा उन प्रकारों को परिभाषित करने की अनुमति देती है जहां कंपाइलर द्वारा किनारे के मामलों को आपके लिए चेक किया गया है, तो आपको आमतौर पर कोड के अंदर इसे संभालने की ज़रूरत नहीं है, नोडेटर्मेनिस्टिक घटनाओं (फाइलें काम नहीं कर रही हैं, अप्रत्याशित उपयोगकर्ता इनपुट इत्यादि) के बाहर इस तरह के सिस्टम के साथ भाषाएं, रनटाइम से पहले कई त्रुटियां पकड़ी जाएंगी और इसलिए आपके पास कई रक्षात्मक मामले नहीं होंगे।
जब त्रुटि प्रबंधन से बचा नहीं जा सकता है, असफल असफल मुहावरे (जैसे एरलांग) का समर्थन करने वाली भाषाएं उन भाषाओं की तुलना में स्पष्ट रूप से स्पष्ट कोड की अनुमति देगी जो (स्थिर या नहीं) हैं, मुख्य रूप से क्योंकि विशेष मामलों के लिए कोड ' आदर्श निष्पादन पथ के लिए कोड के साथ मिश्रित टी।
प्रोग्रामिंग की असफल-तेज शैली बेहतर कोड पठनीयता और डिबगिंग पर केंद्रित है। उपयोगकर्ता अनुभव एक द्वितीयक लक्ष्य है: उपयोगकर्ता को अजीब त्रुटि संदेश या प्रोग्राम विफलताओं का अनुभव हो सकता है, लेकिन कोड की अधिक गुणवत्ता प्रोग्रामर को आसानी से बग ढूंढने और समस्या को ठीक करने की अनुमति देती है।
रक्षात्मक शैली प्रोग्रामिंग, इसके बजाय, उपयोगकर्ता से और कोड के अन्य हिस्सों से सत्यापन इनपुट पर केंद्रित है। कोड अधिक वर्बोज़ है, क्योंकि प्रोग्रामर को सावधानीपूर्वक इनपुट सत्यापित करना है और त्रुटि के मामले में गहराई से विफल होना है। इससे अधिक कोड (प्रोग्रामर के दृष्टिकोण से) और अधिक मजबूत एप्लिकेशन (उपयोगकर्ताओं के दृष्टिकोण से) तक पहुंच जाता है।
सही नहीं है। आप बिना किसी त्रुटि-हैंडलिंग शैली के असफल-तेज शैली को भ्रमित कर रहे हैं।विफल-तेज शैली अभी भी आपके प्रोग्राम को त्रुटियों को पकड़ने और उपयोगकर्ता को परेशान किए बिना उनसे पुनर्प्राप्त करने की अनुमति देती है। – Deestan
जाहिर है, उपयोगकर्ता असफल शैली के साथ कम छोटी गाड़ी सॉफ्टवेयर के लाभ भी प्राप्त करता है। मैं कहूंगा कि असफलता सही इनपुट क्या है और गलत इनपुट क्या है, और वास्तव में इसे लागू करने में स्पष्टता के बारे में है। स्पष्टता हमेशा बेहतर प्रोग्रामिंग पैदा करती है। इनपुट में त्रुटियों को इस तरह से ध्वजांकित किया जाना चाहिए (ऐप को अपरिभाषित भूमि में सीमित करने के बजाय), लेकिन यह ऐप को इस त्रुटि को सुंदर और सहजता से संभालने से नहीं रोकता है। मुझे लगता है कि आप झूठी डिचोटोमी स्थापित कर रहे हैं। – harms
गलत जवाब। Erlang के संदर्भ में, जिसके लिए सवाल पूछा गया था, रक्षात्मक प्रोग्रामिंग से बचने के लिए और अधिक मजबूत दृष्टिकोण है और केवल अपमानजनक प्रक्रिया "दुर्घटना" दें। एक और प्रक्रिया उचित कार्यों को ठीक करने के लिए ले जाएगी। जावा में, जिसे आप अनुभव करते हैं, आपके पास रक्षात्मक होने के अलावा कोई विकल्प नहीं है क्योंकि यह एक साझा-राज्य समरूपता मॉडल के साथ एक अनिवार्य भाषा है। चूंकि एरलांग संदेश-पासिंग समेकन के साथ एक कार्यात्मक भाषा है, और क्योंकि प्रक्रियाओं के बीच दोषों को संवाद करने के लिए तंत्र हैं, यह पूरी तरह ठीक है और असफल होने के लिए बेहतर है। – dsmith
जो आर्मस्ट्रांग के thesis के अनुभाग 4.3 और 4.4 देखें।
लिंक टूटा हुआ है, लेकिन यहां काम करने वाला एक है: http://erlang.org/download/armstrong_thesis_2003.pdf –
धारा 4.5 भी मेरी राय में प्रासंगिक है। –
मैं परंपरा के साथ तोड़ने जा रहा हूं और पूछता हूं कि इसे समुदाय विकी क्यों बनाया गया था। :) –
क्या मुझे इसे एक समुदाय विकी नहीं बनना चाहिए? मुझे यकीन नहीं है कि कौन सी चीज एक समुदाय विकी है और जो नहीं है। – Zubair
सामुदायिक विकी के बारे में बड़ी बात यह है कि लोग इसे ठीक करने के लिए किसी भी उत्तर को संपादित कर सकते हैं और उत्तर देने वाले उपयोगकर्ता को कोई अपवर्तित बिंदु नहीं है, जबकि सामान्य मोड अंक देता है और केवल न्यूनतम संख्या वाले उपयोगकर्ता उत्तर संपादित कर सकते हैं। –