क्या अपवाद पदानुक्रम का एक सिद्धांत है?


18

मैं एक दर्जन प्रोग्रामिंग भाषाओं से परिचित हूं, जिनमें किसी तरह से अपवाद हैं, फिर भी मुझे दो "पैथोलॉजिकल" प्रवृत्तियां देखने को मिलीं।

  1. इसमें कोई सामान्य पैटर्न या अपवादों का पदानुक्रम नहीं लगता है। प्रत्येक भाषा मूल रूप से अपना स्वयं का संस्करण रोल करती है, और यदि अपवाद इसे मानक में बनाते हैं, तो मानक में पाए जाने वाले अपवादों के प्रकार बल्कि मनमाने ढंग से होंगे (ज्यादातर वे जो भाषा उपकरण बनाते समय कार्यान्वित किए गए थे, जैसे पठन स्रोत कोड स्ट्रिंग या डिबग करने के लिए एक अपवाद, या जो तब होता है जब फ़ाइल नहीं मिल सकती है आदि)

  2. भाषा द्वारा परिभाषित अपवाद उपयोगकर्ता कार्यक्रमों द्वारा बहुत कम उपयोग किए जाते हैं। आमतौर पर एक या दो लोकप्रिय अपवाद होंगे (उदाहरण के लिए "लागू नहीं")। हालांकि अधिकांश बार प्रोग्रामर अपने अपवाद बनाएंगे। (उदाहरण के लिए, नए संख्यात्मक प्रकार या नए संग्रह प्रकार बनाने के लिए इसकी तुलना करें)।

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

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

इस पत्र का तर्क है कि आलसी कार्यात्मक प्रोग्रामिंग न केवल अंतर्निहित अपवाद हैंडलिंग तंत्र को अनावश्यक बनाती है, बल्कि उन अपवादों को विकसित करने और प्रोग्राम को बदलने के लिए एक शक्तिशाली उपकरण प्रदान करती है।

(अपवादों का एक कार्यात्मक सिद्धांत, माइक स्पिवी, 1988)

लेकिन मुझे लगता है कि अपवाद अच्छे हैं। मैं अपवादों का उपयोग करने वाले कार्यक्रमों को बदलना नहीं चाहता, इसके विपरीत, मैं अपवादों के उपयोग को कम अराजक बनाना चाहता हूं।

प्रश्न:

क्या कोई अपवाद का सिद्धांत है? यदि हां, तो इसे क्या कहा जाता है? आधार के आधार पर आधारशिला काम करती है, यदि कोई हो, तो क्या होगा?


अपवाद एक नया आविष्कार हैं, जो शायद ~ 20yr पुराने से कम है, जो कुछ हद तक C के "लॉन्जम्प" से उत्पन्न होता है। वे ज्यादातर OOP से जुड़े होते हैं। ऐसा लगता है कि एक आदर्श उपयोग / सिद्धांत / सर्वोत्तम प्रथाओं अभी भी विकास के अधीन हैं। जावा में अधिक विस्तृत मॉडल में से एक है। नोट करते समय अपवादों से संबंधित कई "एंटीपैटर्न" हैं। इसमें से कुछ "दोष सहिष्णु कंप्यूटिंग" के सिद्धांत से जुड़ा हुआ है, जो समग्र रूप से कुछ हद तक लगता है।
vzn

आप अपवादों को निरंतरता सिद्धांत का सबसेट मान सकते हैं। देखें en.wikipedia.org/wiki/Continuation
jmite

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

"भाषा द्वारा परिभाषित अपवाद उपयोगकर्ता कार्यक्रमों द्वारा बहुत कम उपयोग किए जाते हैं।" ये बिल्कुल सही है! कस्टम अपवादों को परिभाषित करना बहुत कम ही आवश्यक है। उदाहरण के लिए अजगर और इसकी stdlib 160 अपवादों की तरह कुछ परिभाषित करते हैं। संभावना है कि आप जिस अपवाद के बारे में सोच रहे हैं उसे परिभाषित नहीं किया गया है, बहुत छोटा है। इन अपवादों में से कुछ (अधिकांश?) व्यापक रूप से ज्ञात नहीं हैं। उदाहरण के लिए, हर कस्टम कंटेनर के LookupErrorलिए पूरी तरह से ठीक होगा , लेकिन मैं बहुत से लोगों को यह भी नहीं पता है कि यह मौजूद है।
बाकुरू

1
@jmite इस विषय से पहले अपवादों के साथ एक और मुठभेड़ बेनजामिन सी। पियर्स की पुस्तक प्रकार और प्रोग्रामिंग लैंग्वेज से हुई थी। जहां वह एक प्रकार के फ़ंक्शन को परिभाषित करने के संदर्भ में त्रुटियों का उल्लेख करता है। यानी उनके दृष्टिकोण से, त्रुटियां अभी तक कार्यों से लौटे हुए एक और मूल्य हैं (और दूसरे तर्क के साथ वे एक संपूर्ण प्रकार बनाते हैं, अगर मुझे ऐसा कहने की अनुमति है)।
wvxvw

जवाबों:


8

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

  • बी। रैंडेल, सॉफ्टवेयर फॉल्ट टॉलरेंस के लिए सिस्टम संरचना।
  • जेबी गुडएनफ। अपवाद हैंडलिंग: मुद्दे और एक प्रस्तावित संकेतन।
  • जेबी गुडएनफ। संरचित अपवाद हैंडलिंग।
  • बीजी राइडर, एमएल सोफा, डिजाइन ऑफ एक्सेप्शन हैंडलिंग पर प्रभाव।
  • डी। टेलर, ए। स्पिवैक, टी। वरोक्वाक्स, मुझे पकड़ो अगर तुम कर सकते हो: ओडैमल में टाइप-सेफ, पदानुक्रमित, हल्के, बहुरूपी और कुशल त्रुटि प्रबंधन।
  • एक्स। लेरॉय, एफ। पेसाक्स, बिना किसी अपवाद के टाइप-आधारित विश्लेषण।
  • आर। मिलर, ए। त्रिपाठी, ऑब्जेक्ट-ओरिएंटेड सिस्टम्स में अपवाद हैंडलिंग के मुद्दे।
  • एस। ड्रू, केजे गफ, जे। लेडरमैन, जीरो-ओवरहेड एक्सेप्शन हैंडलिंग को लागू करना।
  • बी। स्ट्रॉस्ट्रुप, अपवाद सुरक्षा: अवधारणा और तकनीक।
  • डी। मलेरी, जे। एल्ड्रिच, प्रैक्टिकल एक्सेप्शन स्पेसिफिकेशंस।
  • एच। नैकानो, ए कंस्ट्रक्टिव फॉर्मलाइज़ेशन ऑफ़ द कैच एंड थ्रो मैकेनिज़्म।
  • ए। नैनेव्स्की, ए मॉडल कैलकुलस फॉर एक्सेप्शन हैंडलिंग।
  • पी। ग्रोट, अपवाद हैंडलिंग की एक सरल गणना।
  • एच। थीलेके, राज्य की उपस्थिति में अपवाद और निरंतरता पर।
  • JG Riecke, H. Thielecke, Typed Exception and Continuations Can’t Macro-Express प्रत्येक एक दूसरे को।
  • एम। वैन डोरेन, ई। स्टेगमैन, एंकरेड एक्सेप्शन डिक्लेरेशन का उपयोग करके अनचेक किए गए अपवादों की लचीलेपन के साथ जाँच किए गए अपवादों की लयबद्धता का संयोजन।
  • जेए वॉन, जावा-शैली के अपवादों की एक तार्किक व्याख्या।
  • एस। मार्लो, एस। पीटन जोन्स, ए। मोरन, हास्केल में एसिंक्रोनस अपवाद।
  • बी। जैकब्स, एफ। पिसेन्स, फेलबॉक्सेज: प्रोवाइफली सेफ एक्सेप्शन हैंडलिंग।

वाह, बहुत बहुत धन्यवाद! सकारात्मक उत्तर के साथ वापस आने के लिए मुझे कुछ महीने लगेंगे (यदि अधिक नहीं) :) अब मैं कुछ किताबों के बीच फटा हुआ हूँ, न जाने कहाँ से शुरू करूँ!
wvxvw

2
इनमें से बहुत सारे पेपर प्रोग्रामिंग भाषाओं में अपवादों को लागू करने या मॉडलिंग करने के बारे में हैं, न कि एक अपवाद पदानुक्रम को कैसे डिज़ाइन किया जाए। क्या आप संबंधित कागजात के लिए सूची को ट्रिम कर सकते हैं?
गिल्स एसओ- बुराई को रोकना '

@Gilles मूल प्रश्न थोड़ा अस्पष्ट था। मुझे लगता है कि उपयुक्त अपवादों के रूप में जो मायने रखता है वह ज्यादातर आवेदन पर निर्भर करता है। अपवादों के साथ एकमात्र वास्तविक सैद्धांतिक समस्या अपवादों के माध्यम से (1) युग्मित असंबंधित मॉड्यूल के बीच का व्यापार है (यही कारण है कि जावा के बाद कोई भी भाषा अनिवार्य अपवाद विनिर्देश नहीं है), (2) एक मॉड्यूल के उपयोगकर्ता को कुछ संकेत देते हैं कि किस प्रकार के क्षरण की उम्मीद है , और (3) संकलक त्रुटि से निपटने में मदद करते हैं। जहाँ तक मैं देख सकता हूँ, अभी तक इस पहेली का कोई ठोस हल नहीं निकला है।
मार्टिन बर्गर

6

मुझे नहीं पता कि कोई सिद्धांत है या नहीं, लेकिन एक उभरता हुआ प्रायोगिक विज्ञान हो सकता है।

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

नवंबर 1991 में पालो अल्टो [C ++ मानकीकरण] बैठक में, हमने जिम मिशेल (पूर्व में जेरॉक्स PARC से) से व्यक्तिगत अनुभव और डेटा दोनों के साथ समाप्ति शब्दार्थ के लिए तर्कों का एक शानदार सारांश सुना। जिम ने 20 वर्षों की अवधि में आधा दर्जन भाषाओं में अपवाद हैंडलिंग का उपयोग किया था और ज़ेरॉक्स के सेडर / मेसा सिस्टम के मुख्य डिजाइनरों और कार्यान्वयनकर्ताओं में से एक के रूप में फिर से शुरू होने वाले शब्दार्थ का एक प्रारंभिक प्रस्तावक था। उनके संदेश को समाप्त कर दिया गया था, फिर से शुरू करने पर पसंद किया जाता है; यह विचार का विषय नहीं है बल्कि वर्षों के अनुभव का विषय है। फिर से शुरू करना आकर्षक है, लेकिन वैध नहीं है। उन्होंने कई ऑपरेटिंग सिस्टम के अनुभव के साथ इस कथन का समर्थन किया। प्रमुख उदाहरण देवदार / मेसा था: यह उन लोगों द्वारा लिखा गया था, जिन्हें पसंद और फिर से शुरू किया गया था, लेकिन उपयोग के दस साल बाद, आधी मिलियन लाइन प्रणाली में फिर से शुरू होने का केवल एक उपयोग था - और वह एक संदर्भ जांच थी। क्योंकि इस तरह की संदर्भ जांच के लिए फिर से शुरू करना आवश्यक नहीं था, उन्होंने इसे हटा दिया और सिस्टम के उस हिस्से में एक महत्वपूर्ण गति में वृद्धि देखी। प्रत्येक मामले में जहां बहाली का उपयोग किया गया था - दस वर्षों में - एक समस्या बन गई थी और एक अधिक उपयुक्त डिजाइन ने इसे बदल दिया था। मूल रूप से, पुनरारंभ के प्रत्येक उपयोग ने अमूर्तता के अलग स्तर को रखने में विफलता का प्रतिनिधित्व किया था। प्रत्येक मामले में जहां बहाली का उपयोग किया गया था - दस वर्षों में - एक समस्या बन गई थी और एक अधिक उपयुक्त डिजाइन ने इसे बदल दिया था। मूल रूप से, पुनरारंभ के प्रत्येक उपयोग ने अमूर्तता के अलग स्तर को रखने में विफलता का प्रतिनिधित्व किया था। प्रत्येक मामले में जहां बहाली का उपयोग किया गया था - दस वर्षों में - एक समस्या बन गई थी और एक अधिक उपयुक्त डिजाइन ने इसे बदल दिया था। मूल रूप से, पुनरारंभ के प्रत्येक उपयोग ने अमूर्तता के अलग स्तर को रखने में विफलता का प्रतिनिधित्व किया था।

C ++ में असली जीत RAII होती है , जो त्रुटियों के दौरान संसाधन के निपटारे को संभालने में बहुत आसान बनाती है। (यह करने की आवश्यकता के साथ दूर नहीं करता है throwऔर try- catch, लेकिन इसका मतलब है कि आप की जरूरत नहीं है finally।)

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

दूसरी बात जो लोग वर्षों से सीखते आ रहे हैं वह यह है कि अपवाद विनिर्देशों को किसी भाषा में सही ढंग से रखा जाना कठिन है। उदाहरण के लिए इसे देखें: http://www.gotw.ca/publications/mill22.htm , या यह: http://www.gotw.ca/gotw/082.htm । (और यह सिर्फ C ++ नहीं है, जावा प्रोग्रामर्स के पास चेक बनाम अनियंत्रित अपवादों के साथ अपने अनुभवों के बारे में लंबे तर्क हैं ।)

अपवादों के इतिहास पर थोड़ा। क्लासिक पेपर है: जॉन बी। गुडेनफ: "अपवाद हैंडलिंग: मुद्दों और एक प्रस्तावित संकेतन," सांप्रदायिक। एसीएम 18 (12): 683-696, 1975। लेकिन इससे पहले अपवादों को जाना जाता था। मेसा उनके पास लगभग 1974 में था, और PL / I के पास भी हो सकता था। Ada में 1980 से पहले एक अपवाद तंत्र था। मेरा मानना ​​है कि C ++ के अपवादों को 1976 से लगभग बारबरा लिस्कॉव की CLU प्रोग्रामिंग भाषा के साथ अनुभव से सबसे अधिक प्रभावित किया गया था। Barbara Liskov: "CLU का इतिहास," प्रोग्रामिंग भाषाओं के इतिहास में --- II , थॉमस जे। बर्गिन, जूनियर और रिचर्ड जी। गिब्सन, जूनियर (एड्स)। पीपी। ४ p१-५१०, एसीएम, १ ९९ ६


यह दिलचस्प है और मुझे बेहतर उत्तर देने के लिए अधिक शोध करना होगा। लेकिन अब तक: मुझे पता है कि C ++ में अपवादों का उपयोग करने के लिए बहुत सख्त आपत्ति है (शायद एक किस्सा है, लेकिन iirc Google कोडिंग सम्मेलनों में अपवादों का उपयोग करने से मना किया गया है)। जावा जाँच अपवाद निश्चित रूप से एक अनूठा और इस प्रकार दिलचस्प प्रयोग है, लेकिन इस सुविधा ने अपने इतिहास के दौरान बहुत सारे बुरे क्रेडिट अर्जित किए हैं ... ज्यादातर लोग उन्हें केवल रनटाइम पर ही वापस कर देते हैं (हालांकि यह सिंटैक्स से संबंधित हो सकता है)।
wvxvw

मैं अपवादों के सामान्य लिस्प वर्गीकरण से अधिक परिचित हूं, जहां उन्होंने (हालांकि थोड़ी सफलता के साथ) उन्हें खतरे के स्तर के अनुसार विभाजित किया, जो उन्होंने कार्यक्रम के लिए किया था। जैसे serious-conditionबनाम simple-condition। मैं अब जेएल ऑस्टिंग भी पढ़ रहा हूं, जहां वह त्रुटियों को (प्रोग्रामिंग से असंबंधित) समूहों में वर्गीकृत करता है, इस आधार पर कि सिस्टम कैसे कार्य करने में विफल रहा (उदाहरण के लिए, अनुचित इरादे बनाम इस्तेमाल किए गए अनुचित भागों)। जो तुरंत प्रोग्रामिंग के लिए लागू नहीं है, लेकिन कुछ शोधन के बाद हो सकता है।
wvxvw

@ लॉन्ड्रिंग लॉजिक मैंने अपडाउन किया है क्योंकि आपने बताया है कि C ++ एक्सपट्र्स सक्सेज क्यों हैं और फीचर्स के शिक्षित समावेश से भाषा नष्ट हो सकती है।
वैल

@wvxvw very strong objectionC ++ में अपवाद दो तथ्यों से आता है: कोई finallyनिर्माण नहीं है और अपवादों का उपयोग कोई और नहीं करता है। पहली समस्या दूसरी को भी बढ़ाती है। यही है, जब आपके पास कोई finallyनहीं होता है, तो अपवाद होने पर आप संसाधन को बंद नहीं कर सकते। क्योंकि कोई भी अपवाद का उपयोग नहीं करता है, सभी फ़ंक्शन / एपीआई उनसे बचते हैं, आपको अपने कोड में उनसे लाभ प्राप्त करना शुरू करने के लिए अपने अपवाद के साथ सभी कार्यों को लपेटते हुए पूरे पारंपरिक सी ++ इन्फ्रास्ट्रक्चर के पुनर्निर्माण में बहुत निवेश करना चाहिए। लेकिन finallyयह दृष्टिकोण असंभव बना देता है।
वैल

@wvxvw: Google के सम्मेलन मॉड्यूल (.so) की सीमाओं के अपवादों को फेंकने पर प्रतिबंध लगाते हैं। ऐसा इसलिए है क्योंकि C ++ में अपवाद रन-टाइम प्रकार की जानकारी (RTTI) का उपयोग करते हैं, और Linux ने रन-टाइम टाइपिंग को लागू करने का अच्छा काम नहीं किया। लिनक्स में आप मॉड्यूल के बीच केवल रन-टाइम प्रकारों को पार कर सकते हैं यदि आप मॉड्यूल को एक ही कंपाइलर के समान संस्करण के साथ संकलित करते हैं और libstdc ++ के समान संस्करण के खिलाफ लिंक करते हैं। वास्तव में यह लिनक्स समुदाय द्वारा सामान्य रूप से C ++ की अस्वीकृति है, विशेष रूप से अपवादों की अस्वीकृति नहीं।
भटकना तर्क

3

मुझे केवल यह बताना चाहिए कि अपवाद कम्प्यूटेशनल प्रभाव का मामला है । अन्य कम्प्यूटेशनल प्रभाव परस्पर अवस्था, I / O, गैर-नियतात्मकता, निरंतरता और कई अन्य हैं। इसलिए आपका प्रश्न अधिक सामान्यतः पूछा जा सकता है: हम कम्प्यूटेशनल प्रभावों के पदानुक्रम कैसे बनाते हैं, हम उन्हें कैसे व्यवस्थित करते हैं, और हमारे पास हमारे पास क्यों हैं, और अन्य नहीं, आदि।


1
मुझे लगता है कि यह पूरी तरह अप्रासंगिक है। सवाल अपवादों की धारणा के बारे में नहीं है, लेकिन त्रुटियों के लिए इसे मैप करने के बारे में है - मुझे लगता है कि पीएलटी परिप्रेक्ष्य से इसका वर्णन करने का सही तरीका अपवाद पदानुक्रमों का सिद्धांत होगा।
गिल्स एसओ- बुराई को रोकना '

हम्म, तुम सही हो। मैंने इसे इंगित करने के लिए उत्तर निर्धारित किया है, लेकिन मुझे लगता है कि इसे हटाने की कोई आवश्यकता नहीं है। तुम क्या सोचते हो?
बेफ़िक बाउर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.