अपवाद संचालन

अपवाद संचालन एक प्रोग्रामिंग भाषा संरचना या कम्प्युटर हार्डवेयर यंत्रावली है जिसे घटने वाले अपवादों, एक विशेष अवस्था जो प्रोग्राम कार्यान्वयन की सामान्य गति को बदल देती है, के संचालन के लिए डिजाईन किया गया है।

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

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

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

प्रसंस्करण के विचार से, हार्डवेयर व्यवधान फिर से शुरू करने योग्य अपवादों के सामान हैं, हलांकि वे प्रयोगकर्ता के प्रोग्राम फ्लो से विशिष्ट रूप से जुड़े नहीं हैं।

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

जावा या NET जैसे रूटीन इंजन परिवेशों में, ऐसे औजार मौजूद रहते हैं जो रूटीन से जुड़े होते हैं और हर समय जो रूचि के अपवाद पैदा होते हैं, वे उन छुपी हुई सूचनाओं को दर्ज करते हैं जो अपवाद के फेंके जाने के समय स्मृति में मौजूद रहती है (कॉल स्टैक तथा हीप मान). इन उपकरणों को स्वचालित अपवाद संचालन या भूल रोकनेवाला औजार कहा जाता है और ये अपवादों के "मुख्य कारण" की सूचना देते हैं।

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

अपवाद सुरक्षा

कोड के एक टुकड़े को अपवाद-सुरक्षित कहा जाता है, यदि कोड के अंदर रन-टाईम असफलता समृति रहस्योद्घाटन, जमा आकड़ा अस्पष्टता, या अमान्य परिणाम जैसे खराब प्रभाव पैदा नहीं करती. अपवाद-सुरक्षा कोड को कोड में रखे गए इनवैरिअंट्स को संतुष्ट करना चाहिए, भले ही अपवाद घटित हों. अपवाद सुरक्षा के कई स्तर हैं:

विफल पारदर्षिता, जिसे नो थ्रो गारंटी के रूप में भी जाना जाता है: परिचालन के सफल होने और यहां तक कि अपवाद वाली स्थितियां होने पर भी सभी जरूरतों को पूरा करने की भी गारंटी होती है। यदि कोई अपवाद होता है, यह अपवाद को आगे नहीं बढ़ने देता. (अपवाद सुरक्षा का सर्वश्रेष्ठ स्तर.)
प्रतिबद्ध या रोलबैक अर्थविज्ञान, मजबूत सुरक्षा अपवाद या परिवर्तनहीन गारंटी के रूप में भी ज्ञात: परिचालन असफल हो सकता है, लेकिन विफल परिचालन में यह गारंटी होती है कि कोई पार्श्व प्रभाव नहीं पड़ेगा अतएव सभी आकड़े अपने सही रूप में होंगे। ^[2]
आधारभूत अपवाद सुरक्षा : विफल परिचालन के आंशिक निष्पादन से पार्श्व प्रभाव पैदा हो सकते हैं, लेकिन स्टेट के इनवैरिअंट्स को संरक्षित कर लिया जाता है। कोई भी जमा किये हुए डेटा में मान्य मूल्य रहते हैं, भले ही अपवाद के पहले से ही डेटा अलग मूल्य का हो।
न्यूनतम सुरक्षा अपवाद, नो-लीक गारंटी के रूप में भी ज्ञात: विफल परिचालन का आंशिक निष्पादन अमान्य आकड़ों को जमा कर सकता है लेकिन किसी दुर्घटना का कारण नहीं बनता और कोइ भी संसाधन रहस्योद्घाटित नहीं होता।
अपवाद हीन सुरक्षा : कोई गारंटी नहीं बनायी जाती है। (सुरक्षा अपवाद का सबसे बुरा स्तर)

उदाहरण के लिए, C++'s std :: वेक्टर या जावा एरॉय सूची जैसे एक समार्ट वेक्टर टाईप पर विचार करें। जब एक आइटम x को वेक्टर v से जोड़ा जाता है तो वेक्टर को चाहिए कि वह x को वस्तु के इन्टरनेट सूची से जोड़े और उस गिनती क्षेत्र को अपडेट करे जो बताती है कि v में कितने पदार्थ हैं। नयी स्मृति को आबंटित करने की भी जरूरत पड़ सकती है यदि मौजूद क्षमता पर्याप्त बड़ी नहीं है। यह स्मृति आवंटन विफल हो सकता है और एक अपवाद को पैदा करता है। इस वजह से, एक वेक्टर जो विफल पारदर्शिता प्रदान करता है उसे लिखना बहुत मुश्किल या असंभव होता है। हालांकि, वेक्टर काफी हद तक एक मजबूत अपवाद गारंटी आसानी से दे सकता है, इस मामले में, v का x में प्रवेश करना या तो सफल हो सकता है या v अपरिवर्तित रहता है। अगर वेक्टर केवल आधारभूत अपवाद सुरक्षा गारंटी प्रदान करता है, अगर अंतर्वेश असफल होता है, v x को धारित कर भी सकता है और नहीं भी, लेकिन यह कम से कम सामान अवस्था में रहेगा. हालांकि, अगर वेक्टर केवल न्यूनतम गारंटी देता है, यह संभव है कि वेक्टर अमान्य हो जाये. उदाहरण के लिए, शायद v का क्षेत्र आकार बढ़ाया गया था लेकिन वास्तव में अवस्था को असंगत करते हुए x को प्रवेश नहीं कराया गया था। बेशक, बिना गारंटी के, प्रोग्राम दुर्घटनाग्रस्त हो सकता है; शायद वेक्टर के विस्तार की जरूरत थी लेकिन वह स्मृति को आबंटित नहीं कर सका और अमान्य पते पर स्मृति का स्पर्श करते हुए आगे के क्षेत्र की अंधाधुंध खुदाई कर दी मानो आबंटन सफल हो गया हो।

आमतौर पर कम से कम बुनियादी अपवाद सुरक्षा की आवश्यकता पड़ती है। विफल पारदर्शिता को लागू करना कठिन है और आमतौर पर पुस्तकालयों में यह संभव नहीं है, जहां उपयोग की पूरी जानकारी उपलब्ध नहीं है।

अपवाद संचालन का सत्यापन

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

यह सुनिश्चित करने के लिए कि एक सॉफ्टवेर विकास जीवनचक्र प्रक्रिया का पूरा अर्थपूर्ण प्रतिगमन विश्लेषण किया जा सकता है, कोई भी अपवाद संचालन जांच पूर्णतः स्वचालित होना चाहिए और परीक्षण के मामले वैज्ञानिक, दुहराए जाने योग्य आचरण में ही पैदा किये जाने चहिये. ऐसी कई वाणिज्यिक व्यवस्थाएं हैं जो कि इस तरह का परीक्षण करती हैं।

प्रोग्रामिंग भाषाओं में अपवाद सहायता

कई कंप्यूटर भाषाएं जैसे, एक्शन स्क्रिप्ट, एडीए, ब्लीट्जमैक्स, C++, D, ECMA लिपि, इफेल, जावा, एमएल, ऑब्जेक्ट पास्कल (जैसे डेल्फी, मुफ्त पास्कल और उसी के जैसी) ऑब्जेक्टिव-C Ocaml (प्रारूप 5 के रूप में), PL /1, प्रोलोग, पिथोन, रिअल बेसिक, रूबी, दृश्य प्रलोग तथा अधिकतर नेट भाषाएं अपवाद एवं अपवाद संचालन की सहायता के लिए बनी हैं। उन भाषाओं में, अपवाद की एक घटना (अधिक संक्षेप में, भाषा के द्वारा अपवाद संचालन) कार्य प्रणाली कॉल की ढेर के माध्यम से अपवाद संचालक को प्राप्त कर लेने तक सर्च बैक करती है, खोज प्रगति के रूप में कुछ भाषाओं को स्टैक को खोलने का आमंत्रण देते हुए. अर्थात्, यदि कार्य प्रणाली f अपवाद E के लिए एक संचालक H, कॉल कार्य प्रणाली g को धारित करती है, कार्य प्रणाली g को कॉल करती है, जो बदले में कार्य प्रणाली h को कॉल करती है और h में एक अपवाद E घटित होता है, तब कार्य प्रणाली h और g समाप्त हो सकती है, H में मौजूद f E का संचालन करेगा। आम लिस्प अपवाद संचालक को कॉल करता है और स्टैक को खोलता नहीं है। यह ठीक उसी जगह से कम्प्युटेशन को जारी रखने की अनुमति देता है, जहां त्रुटि पैदा हुई थी (इस सटीक एक ही जगह है जहाँ त्रुटि हो गई (उदाहरण के लिए जब एक पहले से लापता फ़ाइल अब उपलब्ध हो जाती है). मिथरिल का स्टैकलेस कार्यान्वयन स्टैक को खोले बिना स्थिर-समय अपवाद संचालन की सहायता करता है।

मामूली वाक्यात्मक मतभेदों को छोड़कर, केवल दो अपवाद संचालन विधियां उपयोग में हैं सबसे लोकप्रिय विधि में, एक अपवाद की शुरुआत एक अपवाद पदार्थ (जैसे जावा, या ओब्जेक्ट पास्कल), या एक विशेष बढ़ाने योग्य गिने हुए टाइप के मूल्य (जैसे एडीए के साथ) के साथ एक विशेष कथन (फेंको, या बढ़ाओ) के द्वारा की जाती है। अपवाद संचालकों के लिए मार्कर क्लॉज (कोशिश करना, या भाषा के ब्लॉक स्टार्टर जैसे कि शुरू करना) के साथ गुंजाइश शुरू होती है और प्रथम संचालक क्लॉज (पकड़ना, छोड़ना, बचाना) की शुरुआत में खत्म हो जाती है। कई संचालक क्लॉज और उस अपवाद टाइप का जिसे संचालित करते हैं, का पालन करते हैं और अपवाद पदार्थ के लिए जिस नाम का वे प्रयोग करते हैं, उसका विस्तृत विवरण देते हैं। कुछ एक भाषाएं भी क्लॉज (अतिरिक्त) को परमिट करती हैं जो उस हालत में उपयोग की जाती हैं जब संचालक की गुंजाइश की पहुंच के पहले कोई अपवाद घटित नहीं होता। एक संबंधित क्लॉज (finally, या ensure) अधिक सामान्य है जिसका निष्पादन आम तौर पर बॉडी के अपवाद-संचालन ब्लॉक के अंदर अधिग्रहण किए गए संसाधनों को रिलीज़ करने के लिए किया जाता है चाहे एक अपवाद घटित हो या नही. विशेष रूप से, C++ को निर्माण की जरूरत नहीं है और यह प्रदान भी नहीं करता है और संसाधन अधिग्रहण-शुरूआत तकनीक है का उपयोग इस तरह के संसाधन को मुक्त करने के लिए किया जाना चाहिए। ^[3] अपनी पूर्णता में, अपवाद संचालन कोड इस तरह का दिख सकता है (जावा -जैसे छद्म कोड में; ध्यान दें कि EmptyLineException नामक एक अपवाद टाइप कोड को कहीं घोषित करने की जरूरत पड़ती है): <स्त्रोत lang="csharp">

कोशिश {
लाइन= कंसोल.रीडलाइन ()
यदि (लाइन.लेन्थ () == 0) (
नई खालीलाइनअपवाद फेंकें ("सांत्वना से पढ़ने पर लाईन खाली थी!");;

)

console.printLine (हैलो %s!" %लाइन);
console.printLine ("प्रोग्राम सफलतापूर्वक चला");

) (पकड़ना EmptyLineException ई) (

Console.printLine("हैलो! ");

) पकड़ना (अपवाद ई) (

कंसोल.प्रिंटलाइन ("त्रुटि:" + e.संदेश ());
}अंततः {
कंसोल.प्रिंटलाइन ("प्रोग्राम अब समाप्त");
}
</स्त्रोत>

एक मामूली बदलाव के रूप में, कुछ भाषाएं एक ही संचालक क्लॉज का उपयोग करती हैं, जो अपवाद के वर्ग को आंतरिक रूप सम्हालती हैं।

सी त्रुटि जाँच के विभिन्न साधनों की सहायता करता है लेकिन आम तौर पर "अपवाद संचालन" की सहायता करने के रूप में इसपर विचार नहीं किया जाता. संरचित अपवाद संचालन के लिए पर्ल का वैकल्पिक समर्थन हासिल है।

C++ व्युत्पन्न सन्निहित C++ अपवाद संचालन सहायता को छोड़ देता है क्यों कि यह ऑब्जेक्ट कोड के आकार को मजबूती से बाधा देता है।

इसके विपरीत अपवाद संचालन के लिए पिथोन की सहायता व्यापक और संगत है। रोबुस्ट पिथॉन प्रोग्राम को कुछ परिचालनों को ट्राई:  करने या विभिन्न अपवादों   को पकड़ने के लिए इसकी सहायता के बिना लिखना मुश्किल है।

अपवाद संचालन का कार्यान्वयन

अपवाद संचालन के कार्यान्वयन में विशेष तौर पर एक कोड जनरेटर और रूटीन व्यवस्था के साथ जुड़ा हुआ एक संकलक दोनों शामिल रहते हैं। (यह अपवाद संचालन का C++ तक विस्तार था, जिसने मूल C++ संकलक, सी फ्रौंट के उपयोगी जीवन काल का अन्त कर दिया। ^{[उद्धरण चाहिए]} दोनों योजनाएं सबसे अधिक समान हैं। पहला, गतिशील पंजीकरण, कोड उत्पन्न करता है जो लगातार अपवाद संचालन के बारे में प्रोग्राम अवस्था की संरचनाओं को लगातार सुधारता रहता है।^[4] विशेष तौर पर, यह स्टैक फ्रेम लेआउट में एक नए तत्त्व को जोड़ता है जो यह जानता है कि प्रकार्य या उस फ्रेम के साथ जुड़ी विधि के लिए कैसे संचालक उपलब्ध हैं; यदि अपवाद पैदा होता है तो लेआउट में मौजूद एक संकेतक सही संचालक कोड के लिए रूटीन को निर्देश देता है। यह दृष्टिकोण स्थान के संदर्भ में चुस्त है, लेकिन फ्रेम के प्रवेश और निकास पर निष्पादन को जोड़ देता है। आमतौर पर इसका इस्तेमाल कई एडीए कार्यान्वयन में गया था, उदाहरण के लिए, वहां, जहां जटिल जनन और रूटीन सहायता कई अन्य भाषा वैशिष्ट्य के लिए पहले से ही जरूरी था। गतिशील पंजीकरण, परिभाषित करने में आसान होने के कारण, शुद्धता के प्रूफ के लिए सहज अनुगामी है।^[5]

दूसरी योजना और कई उत्पादन-गुणवत्ता C++ संकलकों में कार्यान्वित की गई, सारणी चालित दृष्टिकोण है। यह संकलन और लिंक समय पर स्थिर सारणियां बनाता है जो प्रोग्राम काउंटर के विस्तार को अपवाद संचालन से संबंधित प्रोग्राम से जोड़ता है।^[6] तो फिर, अगर एक अपवाद फेंका जाता है, रूटीन प्रणाली तालिकाओं के वर्तमान अनुदेश स्थान का अवलोकन करता है और यह निर्धारित करता है कि संचालक क्या रहा है और क्या किए जाने की जरूरत है। उस मामले में जहाँ आपवाद नहीं फेंका जाता, अगरचे स्थान की कीमत पर, यह दृष्टिकोण प्रबंधकारिणी के भार को कम कर देता है, यद्यपि अक्त जगह को रीड-ओनली, विशेष-उद्देश्य डेटा अनुभाग में आबंटित किया जा सकता है, जिन्हें तब तक लोड या पुनस्थापित नहीं किया जाता,

जब तक एक अपवाद को नहीं फेंका जाता.^[7] यह दूसरा दृष्टिकोण भी तार सुरक्षा को हासिल करने की दृष्टि से भी बेहतर है।

साथ ही अन्य पारिभाषिक और कार्यान्वयन योजनाओं को भी प्रस्तावित किया गया है।^[8] उन भाषाओं के लिए जो मेटाप्रोग्रमिंग का समर्थन करती हैं, जो अतरिक्त भार में शामिल नहीं होती और सभी प्रगत हैं।^[9]

अनुबंध डिजाइन पर आधारित अपवाद संचालन

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

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

वस्तु उन्मुख सॉफ्टवेयर निर्माण में बरट्रैंड मेयर द्वारा पहली बार शुरू किया गया "सुरक्षित अपवाद संचालन सिद्धांत' तब इस धारणा से युक्त था कि अपवाद के घटित होने के समय रूटीन केवल दो ही अर्थपूर्ण माध्यम से प्रतिक्रिया करती है:

असफलता, या "सुनियोजित" घबड़ाहट: इसके कॉलर के एक अपवाद को शुरू करते हुए, रूटीन असफल हो जाती है (जिससे कि असमान्य घटना उपेक्षित नहीं होती).

), इनवैरिअंट (सुनियोजित भाग) को पुनर्स्थापित कर ओब्जेक्ट की स्थिति को स्थिर करते हुए.

पुनः प्रयास: एल्गोरिथ्म को फिर जांचें, साधारणत: कुछ मान बदलने के बाद ताकि बाद के प्रयास के सफल होने की बेहतर सम्भावना हो।

यहाँ एफिल वाक्यविन्यास में व्यक्त एक उदाहरण है। यह आश्वस्त करता है कि तीव्र गति से_भेजो रूटीन सामान्यत: संदेश भेजने का एक बेहतर माध्यम है, लेकिन अपवाद शुरू होने पर, यह विफल हो सकता है; यदि ऐसा होता है तो एल्गोरिथ्म इसके बाद धीरे_भेजो का उपयोग करता है, जो प्राय: कम ही विफल होता है। अगर धीरे_भेजो विफल रहता है, कॉलर में अपवाद घटित होने के कारण पूरी भेजी गई रूटीन विकन होनी चाहिए। <स्त्रोत lang="ईफेल"> (भेजें (एम: संदेश) है

- यदि संभव हो तो तीव्र लिंक के माध्यम से m भेजें, या फिर धीमे लिंक के माध्यम से.

स्थानीय

तीव्र_कोशिश किया, धीमा_कोशिश किया: बुलियन

करें

अगर कोशिश किया_ तब तीव्र 
धीमा_कोशिश किया: = सच
भेजें_धीमा (एम)
अतिरिक्त 
कोशिश किया_तीव्र: = सच
भेजें_तीव्र (एम)
अंत

बचाव

अगर कोशिश _ तब धीमा करें 
पुनःप्रयास
अंत

अंत </स्त्रोत> बुलियन स्थानीय चर को शुरू में फाल्स करने के लिए शुरू किया जाता है। अगर भेजो_तीव्र विफल रहता है, तो बॉडी (डू क्लॉज) को दुबारा निष्पादित किया जाएगा, धीमा_भेजें के निष्पादन को उत्पन्न करते हुए. यदि यह धीमा_भेजें का निष्पादन विफल रहता है, तो बचाव क्लॉज नो इंट्री ( अंतिम इफ में कोई अतिरिक्त क्लॉज नहीं होता) के साथ अंत तक बचाव करेगा, पूरे रूटीन निष्पादन को विफल करते हुए.

इस दृष्टिकोण को स्पष्ट रूप से "सामान्य" और "असामान्य" क्या है, को परिभाषित करने का श्रेय है: एक सामान्य मामला जो निष्पादन को उत्पन्न करता है, वह है जिसके करार को रूटीन पूरा नहीं कर पाती.

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

जांचे हुए अपवाद

जावा के डिजाइनर जांचे हुए अपवादों की योजना^[10]^[11] बनाते हैं, जो अपवाद की विशेष ढांचा होते हैं।^[12] जाँच अपवाद जो एक पद्धति उठा सकती है, वे पद्धति के हस्ताक्षर का हिस्सा होते हैं। उदाहरण के लिए, यदि एक पद्धति एक आई0अपवाद फेंक सकती है तो उसे इस तथ्य को अपनी पद्दति हस्ताक्षर में घोषित करना चाहिए। यह कर पाने में विफलता एक संकलन समय त्रुटि को जन्म देता है।

यह अपवाद जांचकर्ताओं के साथ जुड़ी होती है जो कम से कम OCaml के लिए मौजूद रहते हैं।^[13] OCaml के लिए बाहरी उपकरण पारदर्शी (यानी इसे किसी भी वाक्यात्मक एनोटेशन की आवश्यकता नहीं है) और वैकल्पिक (यानी एक प्रोग्राम को बिना अपवाद जांच किए संकलन और चालू करना संभव है, यद्दपि उत्पादन कोड के लिए इसका सुझाव नहीं दिया जाता है) दोनों होते हैं।

Clu प्रोग्रामिंग भाषा के पास इंटरफेस युक्त एक विशेषता थी, कुछ-कुछ वैसी ही जैसा जावा ने बाद में शुरू किया। एक प्रकार्य अपने टाइप में उल्लिखित अपवादों को ही पैदा कर सकता है लेकिन कॉल किया हुआ कोई भी लीक हो रहा अपवाद अपने आप सोल रनटाइम अपवाद, विफल, में बदल जाएगा, संकलन-समय त्रुटि में परिणाम बताने के बावजूद. बाद के, मोड्युला-3 में समान सुविधा थी।^[14] ये सुविधाएं संकलन समय जांच को शामिल नहीं करती जो जांच किए हुए अपवाद की परिकल्पना के केन्द्र में है और जिन्हें जावा के अलावा अन्य किसी प्रोग्रामिंग भाषा में निगमित नहीं किया गया है (2006 तक).^[15]

C++ प्रोग्रामिंग भाषा जांच किए हुए अपवादों के लिए एक वैकल्पिक व्यवस्था करती है जिसे अपवाद विनिर्देश कहा जाता है। डिफ़ॉल्ट रूप से कोई भी प्रकार्य अपवाद थ्रो कर सकता है, लेकिन इसे प्रकार्य हस्ताक्षर में जोड़े गए थ्रो क्लॉज के द्वारा सीमित किया जा सकता है, जो यह विनिर्दिष्ट करता है कि किस अपवाद को थ्रो किया जाय. अपवाद विनिर्देश संकलन समय पर जबरदस्ती लागू नहीं किया जाता. वैश्विक समारोह में उल्लंघन परिणाम को एसटीडी:अप्रत्याशित (std::unexpected) को बुलाया जा रहा है।^[16] एक खाली अपवाद विनिर्देश दिया जा सकता है जो इंगित करता है कि प्रकार्य कोई अपवाद थ्रो नहीं करेंगे। अपवाद संचालन को भाषा के साथ जोड़ते समय इसे डिफॉल्ट नहीं बनाया गया था क्योंकि मौजूदा कोड में बहुत सारे सुधार की जरूरत होती, दुसरी भाषाओं में लिखे कोड के साथ अंत:क्रिया करने में यह अड़चन पैदा करता, तथा स्थानीय स्तर पर यह बहुत सारे संचालक लेखन के लिए प्रोग्रामरों को आकर्षित करता.^[16] खाली अपवाद विनिर्देशों का स्पष्ट उपयोग, हलांकि महत्त्वपूर्ण कोड और स्टैक लेआउट के अनुकूलन प्रदर्शन करने के लिए C++ संकलकों को अनुमति दे सकता है जिसे उस समय दबा देना पड़ता है जब एक प्रकार्य में अपवाद संचालन घटित होता है।^[7] कुछ विश्लेषकों की राय है कि C++ में अपवाद विनिर्देशों के समुचित उपयोग को हासिल करना मुश्किल है।^[17] आगामी C++ भाषा मानक (C++0x) में, वर्तमान संस्करण में सुनिश्चित मानक (C++03) अपवाद विनिर्देश का उपयोग अस्वीकृत हो जाता है।

उपयोग की दृष्टि

जांचे हुए अपवाद, संचित समय पर, एक दिए हुए उपयोग में रनटाइम पर असंचालित अपवाद सरफेसिंग की घटना को कम कर देते हैं; जबकि बिने जांचे हुए अपवाद (रनटाइमअपवाद और त्रुटि) असंचालित रह जाते हैं। ^{[उद्धरण चाहिए]}

हालांकि, जांचे हुए अपवादों को या तो व्यापक थ्रो घोषणाओं, कार्यान्वयन विवरण को व्यक्त करने तथा संपुटीकरण को कम करने की जरूरत होती है, या अस्वस्थ तरीके से-विचारित ट्राई/कैच रूकावटों को बढ़ावा देने की, जो मूल अपवादों को उनके उचित संचालकों से छुपा सकती है।^{[उद्धरण चाहिए]} एक विकसित हो रहे कोडआधार का विचार समय के आधार पर करें। एक इंटरफेस X और Y अपवादों को थ्रो करने के लिए घोषित हो सकती है। कोड को बाद वाले संस्करण में, यदि कोई Z अपवाद थ्रो करना चाहता है, तो यह पहले के उपयोग के विपरीत एक नया कोड बनाएगा. इसके अलावा, अनुकूलक विधि के अनुसार, जहां कोड की एक बॉडी एक इंटरफेस की घोषणा करती है जो उस समय एक अलग कोड की बॉडी द्वारा कार्यान्वित की जाती है इसलिए कि कोड को लगाया जा सके और प्रथम के द्वारा कॉल किया जो सके, अनुकूलक कोड के पास समस्याओं की व्याख्या के लिए एक समृद्ध अपवाद दस्ता हो सकता है, लेकिन घोषित इंटरफेस अपवाद टाइप का उपयोग के लिए इसे मजबूर किया जाता है। ^{[किसके द्वारा?]}

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

थ्रो अपवाद घोषणा या कैच (अपवाद ई) का कम से कम प्रयोग जांच संतुष्ट करने के लिए पर्याप्त होते हैं। जबकि इसका कुछ उपयोग हो सकता है, लेकिन यह अनिवार्य रूप से जांच किए हुए अपवाद तंत्र में गतिरोध उत्पन्न करता है। इसके अतिरिक्त, थ्रो अपवाद सभी कॉलिंग कोड को ऐसा करने के लिए मजबूर करता है। ^{[किसके द्वारा?]}

अनियंत्रित अपवाद टाइप को, सोच विचार के साथ, अवसर के बाहरी स्तर को छोड़कर संचालित नहीं किया जा सकता. ये अक्सर: उन परिदृश्यों का प्रतिनिधित्व करते हैं जो पुन: उसी हालत में आने की अनुमति नहीं देते: रनटाइमअपवाद बार बार प्रोग्रामिंग दोष को प्रतिबिंबित करते हैं,^[19] और त्रुटियां आम तौर पर ठीक न किए जाने वाली जेविएम विफलताओं का प्रतिनिधित्व करती हैं। मत यह है कि उस जांचे हुए अपवादों का साथ देने वाली भाषा में भी ऐसे मामले होते हैं, जहां जांचे हुए अपवादों का उपयोग सही नहीं होता। ^{[किसके द्वारा?]}

अपवाद तुल्यकालिकता

तुल्यकालिक अपवाद जांचे हुए अपवादों की अवधारणा के साथ कुछ-कुछ संबंधित है। तुल्यकालिक अपवाद एक विशेष प्रोग्राम स्टेटमेंट में घटित होते हैं, ऐसी आवस्था में तुल्यकालिक अपवाद व्यवहार में कहीं भी प्रकट हो सकते हैं।^[20]^[21] ऐसा लगता है कि संकलकों द्वारा अतुल्यकालिक अपवाद संचालन की जरूरत नहीं पड़ सकती. उनके साथ प्रोग्राम बनाना भी मुश्किल है। स्वभाविक रूप से अतुल्यकालिक घटनाओं के उदाहरण में एक प्रोग्राम को रोकने के लिए Ctrl-C को दबाना और अन्य निष्पादन के थ्रिड से "रोकिए" या "निरस्त करें" जैसा संकेत प्राप्त करना शामिल हैं।

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

अवस्था प्रणालियां

कोमोन लिस्प, डायलन तथा स्मालटॉक के पास अवस्था प्रणाली^[23] है जिसमें उपर्युक्त अपवाद संचालन प्रणाली शामिल हैं। उन भाषाओं या परिवेशों में एक अवस्था का आगमन (केंट पिटमैन के अनुसार एक " त्रुटि का सामान्यीकरण) एक प्रकार्य को सूचित करता है और अपवाद संचालकों की केवल देरी से स्टैक को खोलने का निर्णय लिया जा सकता है।

अवस्थाएं अपवादों का सामान्यीकरण होती हैं। जब एक शर्त उठता है, एक उपयुक्त अवस्था संचालक को खोजा जाता है और स्टैक ऑडर में, शर्त संचालन के लिए उसे चुना जाता है। अवस्थाएं जो त्रुटियों का प्रतिनिधित्व नहीं करतीं, वे पूरे तौर पर सुरक्षित रूप से असंचालित ही रह सकती हैं, उनका एक मात्र उद्देश्य उपयोगकर्ता की ओर संकेत या चेतावनी को भेजना हो सकता है।^[24]

जारी रहने वाले अपवाद

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

रिस्टार्ट यंत्रावली को नीति से अलग करता है

अवस्था संचालन नीति से यंत्रावली को अलगाव प्रदान करता है। रिस्टार्ट त्रुटियों को ठीक करने के लिए विभिन्न संभव यंत्रावली प्रदान करते हैं, लेकिन दी हुई स्थिति के लिए कौन सी यंत्रावली उपयुक्त है, इसका चुनाव नहीं करते. यही एक अवस्था संचालक का कार्य क्षेत्र है, जिसकी (चूंकि यह उच्चतर- स्तर कोड में अवस्थित होता है) पहुंच व्यापक दृष्टि तक होती है।

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

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

इन्हें भी देखें

सन्दर्भ

↑ सारे एक्सेप्शन संभालते है, जिम विलकॉक्स, http://poliTechnosis.kataire.com/2008/02/all-exceptions-are-handled.html Archived 2010-07-09 at the वेबैक मशीन
↑ "संग्रहीत प्रति". मूल से 3 फ़रवरी 2009 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "ब्जरने स्ट्रोऊस्ट्राप'स FAQ". मूल से 1 मई 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ डी. कैमरून, पी. फॉस्ट, डी. लेन्कोव, एम. मेहता, "अ पोर्टेबल इम्प्लीमेंटेशन ऑफ़ C++ एक्सेप्शन हैंडलिंग", प्रोसेडिंग्स ऑफ़ द C++ कॉन्फेरेन्स (अगस्त 1992) USENIX.
↑ ग्राहम हटन, जोएल राईट, "कम्पाइलिंग एक्सेप्शन करेक्टली Archived 2014-09-11 at the वेबैक मशीन". प्रोसीडिंग्स ऑफ़ द 7थ इंटरनैशनल कॉन्फेरेन्स ऑन मैथेमेटिक्स ऑफ़ प्रोग्राम कंस्ट्रक्शन, 2004
↑ Lajoie, Josée (March–April 1994). "Exception handling – Supporting the runtime mechanism". C++ Report. 6 (3).सीएस1 रखरखाव: तिथि प्रारूप (link)
↑ ^अ ^आ Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN Notices. 33 (8): 40–47. डीओआइ:10.1145/286385.286390.
↑ इंटेल कॉरपोरेशन "हाउ टू इम्प्लीमेंट सॉफ्टवेयर एक्सेप्शन हैंडलिंग Archived 2007-02-13 at the वेबैक मशीन".
↑ एम. होफ, एच. मोसेनबॉक, पी. पिर्केल्बौएर, "ज़ीरो-ओवरहेड एक्सेप्शन हैंडलिंग यूज़िंग मेटाप्रोग्रैमिंग Archived 2016-03-03 at the वेबैक मशीन", प्रोसीडिंग्स SOFSEM'97, नवम्बर 1997, लेक्चर नोट्स इन कम्प्यूटर साइंस 1338, पीपी 423-431.
↑ "गूगल उत्तर: द ऑरिजिन ऑफ़ चेक्ड एक्सेप्शन". मूल से 16 अगस्त 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ LISTSERV 15.0 - RMI-USERS अभिलेखागार^{[मृत कड़ियाँ]}
↑ जावा भाषा विशिष्टता, अध्याय 11.2 http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 Archived 2006-12-08 at the वेबैक मशीन
↑ "ओकैमलेक्स्क - ऐन अनकॉट एक्सेप्शन एनालाइज़र फॉर ऑब्जेक्टिव कमेल". मूल से 24 जुलाई 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "मोडूला-3 - प्रक्रिया के प्रकार". मूल से 9 मई 2008 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "ब्रूस एकल'स माइंडव्यू, इंक: डज़ जावा नीड चेक्ड एक्सेप्शन?". मूल से 5 अप्रैल 2002 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ ^अ ^आ ब्जरने स्ट्रौसट्रप, द C++ प्रोग्रामिंग लैंग्वेज थर्ड एडिशन, एडिसन वेस्ले, 1997. ISBN 0-201-88954-4. पीपी 375-380.
↑ Reeves, J.W. (July 1996). "Ten Guidelines for Exception Specifications". C++ Report. 8 (7).
↑ ब्लूच 2001:178 Bloch, Joshua (2001). Effective Java Programming Language Guide. Addison-Wesley Professional. आई॰ऍस॰बी॰ऍन॰ 0-201-31005-8.
↑ ब्लूच 2001:172
↑ अजगर के लिए सुरक्षित अतुल्यकालिक अपवादों. http://www.cs.williams.edu/~freund/papers/02-lwl2.ps Archived 2006-08-30 at the वेबैक मशीन
↑ "हास्केल में अतुल्यकालिक अपवाद - मार्लो, जोन्स, मोरन (ResearchIndex)". मूल से 2 जून 2008 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "जावा थ्रेड प्रिमिटिव डेप्रेकेशन". मूल से 26 अप्रैल 2009 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "व्हाट कंडीशन (शर्ते) आर रियली अबाउट". मूल से 1 फ़रवरी 2013 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.
↑ "शर्त प्रणाली अवधारणाएं". मूल से 28 जून 2007 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

बाहरी कड़ियाँ

क्रिस्टोफर हिल द्वारा लेख "पीएचपी एक्सेप्शनल हैंडलिंग"
लेख "अचिह्नित अपवाद - विवाद"
गीगी सेय्फैन द्वारा लेख "प्रैक्टिकल C++ एरर हैंडलिंग इन हायब्रिड इन्वायरमेंट्स"
क्रिस्टोफे डे डिनेचिन द्वारा लेख "C++ Exception Handling"
ब्रियन गोटेज़ द्वारा "एक्सेप्शनल प्रैक्टिसेस" लेख
केय्ले लोउडन द्वारा "प्रोग्रामिंग विथ एक्सेप्शन इन C++" लेख
अरुण उदया शंकर द्वारा "ऑब्जेक्ट ओरिएंटेड एक्सेप्शन हैंडलिंग इन पर्ल" लेख
टॉम स्कॉटलैंड एण्ड पीटर पेटर्सन द्वारा "एक्सेप्शन हैंडलिंग इन C विदाउट C++" लेख
वडिम कोकिएलोव द्वारा "स्ट्रक्चर्ड एक्सेप्शन हैंडलिंग बेसिक्स" लेख
जेम्स "जिम" विलकॉक्स द्वारा "ऑल एक्सेप्शन आर हैण्डल्ड" लेख
जॉन एम्. डलुगोस्ज़ द्वारा "ऐन एक्सेप्शनल फिलोसौफी" लेख
गर्ट फॉस्टमैन और डाइटमार विकार्सकी द्वारा "एक्सेप्शन हैंडलिंग इन पेट्री-नेट-बेस्ड वर्कफ्लो मैनेजमेंट" कागज़
पोर्टलैंड पैटर्न स्रोत से वर्णन
मैट पीट्रेक - माइक्रोसॉफ्ट सिस्टम्स जर्नल (1997) द्वारा अ क्रैश कॉर्स ऑन द देपथ्स ऑफ़ विन32 स्ट्रक्चर्ड एक्सेप्शन हैंडलिंग
द ट्रबल विथ चेक्ड एक्सेप्शन - एंडर्स हेजल्स्बर्ग के साथ बातचीत
क्या जावा अपवाद चेक की आवश्यकता है?
एक्सेप्शन हैंडलिंग के समस्याएं और लाभ
.NET पर एक्सेप्शन को समझना और उपयोग करना
जावा एक्सेप्शन हैंडलिंग - जैकॉब जेन्कोव
C++ एक्सेप्शन हैंडलिंग - डैनी कलेव
विज़ुअल प्रोलोग एक्सेप्शन हैंडलिंग (विकी लेख)
जावा एक्सेप्शन के प्रकार
जावा: हाउ टू रीथ्रो एक्सेप्शन विदाउट व्रेपिंग देम. - रॉब ऑस्टिन
हाउ टू हैंडल क्लास कंस्ट्रकटर्स दैट फेल
https://web.archive.org/web/20190409075412/http://www.javacodegeeks.net/

[1] सारे एक्सेप्शन संभालते है, जिम विलकॉक्स, http://poliTechnosis.kataire.com/2008/02/all-exceptions-are-handled.html Archived 2010-07-09 at the वेबैक मशीन

[2] "संग्रहीत प्रति". मूल से 3 फ़रवरी 2009 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[3] "ब्जरने स्ट्रोऊस्ट्राप'स FAQ". मूल से 1 मई 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[4] डी. कैमरून, पी. फॉस्ट, डी. लेन्कोव, एम. मेहता, "अ पोर्टेबल इम्प्लीमेंटेशन ऑफ़ C++ एक्सेप्शन हैंडलिंग", प्रोसेडिंग्स ऑफ़ द C++ कॉन्फेरेन्स (अगस्त 1992) USENIX.

[5] ग्राहम हटन, जोएल राईट, "कम्पाइलिंग एक्सेप्शन करेक्टली Archived 2014-09-11 at the वेबैक मशीन". प्रोसीडिंग्स ऑफ़ द 7थ इंटरनैशनल कॉन्फेरेन्स ऑन मैथेमेटिक्स ऑफ़ प्रोग्राम कंस्ट्रक्शन, 2004

[6] Lajoie, Josée (March–April 1994). "Exception handling – Supporting the runtime mechanism". C++ Report. 6 (3).सीएस1 रखरखाव: तिथि प्रारूप (link)

[cppeh-7] अ ^आ Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN Notices. 33 (8): 40–47. डीओआइ:10.1145/286385.286390.

[8] इंटेल कॉरपोरेशन "हाउ टू इम्प्लीमेंट सॉफ्टवेयर एक्सेप्शन हैंडलिंग Archived 2007-02-13 at the वेबैक मशीन".

[9] एम. होफ, एच. मोसेनबॉक, पी. पिर्केल्बौएर, "ज़ीरो-ओवरहेड एक्सेप्शन हैंडलिंग यूज़िंग मेटाप्रोग्रैमिंग Archived 2016-03-03 at the वेबैक मशीन", प्रोसीडिंग्स SOFSEM'97, नवम्बर 1997, लेक्चर नोट्स इन कम्प्यूटर साइंस 1338, पीपी 423-431.

[10] "गूगल उत्तर: द ऑरिजिन ऑफ़ चेक्ड एक्सेप्शन". मूल से 16 अगस्त 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[11] LISTSERV 15.0 - RMI-USERS अभिलेखागार^{[मृत कड़ियाँ]}

[12] जावा भाषा विशिष्टता, अध्याय 11.2 http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 Archived 2006-12-08 at the वेबैक मशीन

[13] "ओकैमलेक्स्क - ऐन अनकॉट एक्सेप्शन एनालाइज़र फॉर ऑब्जेक्टिव कमेल". मूल से 24 जुलाई 2011 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[14] "मोडूला-3 - प्रक्रिया के प्रकार". मूल से 9 मई 2008 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[15] "ब्रूस एकल'स माइंडव्यू, इंक: डज़ जावा नीड चेक्ड एक्सेप्शन?". मूल से 5 अप्रैल 2002 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[bjarne-exc-16] अ ^आ ब्जरने स्ट्रौसट्रप, द C++ प्रोग्रामिंग लैंग्वेज थर्ड एडिशन, एडिसन वेस्ले, 1997. ISBN 0-201-88954-4. पीपी 375-380.

[17] Reeves, J.W. (July 1996). "Ten Guidelines for Exception Specifications". C++ Report. 8 (7).

[18] ब्लूच 2001:178 Bloch, Joshua (2001). Effective Java Programming Language Guide. Addison-Wesley Professional. आई॰ऍस॰बी॰ऍन॰ 0-201-31005-8.

[19] ब्लूच 2001:172

[20] अजगर के लिए सुरक्षित अतुल्यकालिक अपवादों. http://www.cs.williams.edu/~freund/papers/02-lwl2.ps Archived 2006-08-30 at the वेबैक मशीन

[21] "हास्केल में अतुल्यकालिक अपवाद - मार्लो, जोन्स, मोरन (ResearchIndex)". मूल से 2 जून 2008 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[22] "जावा थ्रेड प्रिमिटिव डेप्रेकेशन". मूल से 26 अप्रैल 2009 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[23] "व्हाट कंडीशन (शर्ते) आर रियली अबाउट". मूल से 1 फ़रवरी 2013 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[24] "शर्त प्रणाली अवधारणाएं". मूल से 28 जून 2007 को पुरालेखित. अभिगमन तिथि 9 अगस्त 2010.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]