एक्सेप्शन हेंडलिंग

"Error handling" redirects here. Not to be confused with Error detection and correction.

This article is about कम्प्यूटिंग. For ज्ञान, see तथ्य की जांच. For और, see समस्या को सुलझाना.

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

परिभाषा

एक अपवाद की परिभाषा इस अवलोकन पर आधारित है कि प्रत्येक प्रक्रिया की एक पूर्व स्थिति होती है, परिस्थितियों का एक समूह जिसके लिए यह सामान्य रूप से समाप्त हो जाता है । एक अपवाद प्रबंधन तंत्र प्रक्रिया को अपवाद बढ़ाने की अनुमति देता है यदि इस पूर्व स्थिति का उल्लंघन किया जाता है, तो उदाहरण के लिए यदि प्रक्रिया को तर्कों के असामान्य समूह पर कहा गया है। अपवाद प्रबंधन तंत्र उस समय अपवाद को संभालता है।

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

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

अपवादों के सीमा और उपयोग पर एक बड़ा प्रभाव सामाजिक दबाव है, अर्थात उपयोग के उदाहरण, सामान्यतः मुख्य पुस्तकालयों में पाए जाते हैं, और तकनीकी पुस्तकों, पत्रिका लेखों और ऑनलाइन चर्चा मंचों एक संगठन के कोड मानकों में कोड उदाहरण है "।

इतिहास

पहला हार्डवेयर अपवाद संचालन 1951 से यूनीवैक में पाया गया। अंकगणितीय अतिप्रवाह ने पता 0 पर दो निर्देशों को निष्पादित किया, जो नियंत्रण को स्थानांतरित कर सकता था या परिणाम को ठीक कर सकता था।

सॉफ्टवेयर अपवाद प्रबंधन 1960 और 1970 के दशक में विकसित हुआ। एलआईएसपी 1.5 (1958-1961) ERROR स्यूडो-फलन द्वारा उठाए जाने वाले अपवादों की अनुमति देता है, ठीक उसी तरह जैसे इंटरप्रेटर या कंपाइलर द्वारा की गई त्रुटियां है।ERRORSET कुंजीशब्द, अपवाद पकड़े गए जो प्रोग्राम को समाप्त करने या डीबगर में प्रवेश करने के अतिरिक्त त्रुटि के स्थितियों में NIL लौटाते हैं।

पीएल/आई ने 1964 के आसपास अपवाद प्रबंधन का अपना रूप प्रस्तुत किया जाता है, जिससे बीच के इकाइयों पर नियंत्रित किया जा सके।

मैकलिस्प ने देखा कि ERRSET और ERR न केवल त्रुटि बढ़ाने के लिए उपयोग किया गया था ], किंतु गैर-स्थानीय नियंत्रण प्रवाह के लिए भी किया गया था, और इस प्रकार दो नए कुंजीशब्द जोड़े गए, CATCH और THROW (जून 1972)। सफाई व्यवहार जिसे अब सामान्यतः अंत में कहा जाता है, को एनआईएल (प्रोग्रामिंग भाषा) (लिस्प का नया कार्यान्वयन) में 1970 के दशक के मध्य में प्रस्तुत किया गया था UNWIND-PROTECT. यह तब सामान्य लिस्प द्वारा अपनाया गया था। इसके समकालीन था dynamic-wind स्कीम में, जिसने क्लोजर में अपवादों को संभाला। स्ट्रक्चर्ड अपवाद प्रबंधन पर पहले पेपर थे Goodenough (1975a) और Goodenough (1975b). बाद में 1980 के दशक से कई प्रोग्रामिंग भाषाओं द्वारा अपवाद प्रबंधन को व्यापक रूप से अपनाया गया है।

हार्डवेयर अपवाद

Main article: Interrupt

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

आईईईई 754 अस्थायी-पॉइंट अपवाद

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

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

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

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

प्रोग्रामिंग भाषाओं में अपवाद समर्थन

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

अपवाद क्या है, इस बारे में उनकी धारणा में प्रोग्रामिंग भाषाएं अधिक हद तक भिन्न हैं। समकालीन भाषाओं को दो समूहों में विभाजित किया जा सकता है:

• भाषाएँ जहाँ अपवादों को प्रवाह नियंत्रण संरचनाओं के रूप में उपयोग करने के लिए रचना कि गयी है: एडीए, मोडुला-3, एमएल, ओकैमल, पीएल/आई, पायथन, और रूबी इस श्रेणी में आते हैं। उदाहरण के लिए, इटेरटर या पायथन|पायथन के पुनरावर्तक बंद करो अपवादों को यह संकेत देने को प्रक्षेप कहते हैं कि पुनरावर्तक द्वारा कोई और सामान नहीं बनाया गया है।
• भाषाएँ जहाँ अपवादों का उपयोग केवल असामान्य, अप्रत्याशित, गलत स्थितियों को संभालने के लिए किया जाता है: C++, java, C या , कॉमन लिस्प, एफिल और मोडुला -2।

पीएल/आई ने गतिशील रूप से सीमा वाले अपवादों का उपयोग किया। पीएल/आई अपवाद प्रबंधन में ऐसी घटनाएँ सम्मिलित हैं जो त्रुटियाँ नहीं हैं, उदाहरण के लिए, ध्यान, फ़ाइल का अंत, सूचीबद्ध चर का संशोधन किया जाता है|

वाक्य - विन्यास

Further information: अपवाद हैंडलिंग सिंटैक्स

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

सामान्य वाक्य-विन्यास अंतरों को छोड़कर, उपयोग में केवल कुछ अपवाद प्रबंधन शैलियाँ हैं। सबसे लोकप्रिय शैली में, एक विशेष कथन द्वारा एक अपवाद प्रारंभिक किया जाता है (throw या raise) एक अपवाद वस्तु के साथ (उदाहरण के लिए जावा या ऑब्जेक्ट पास्कल के साथ) या एक विशेष विस्तार योग्य एन्युमरेटेड प्रकार का मान (जैसे एडा या एसएमएल के साथ)। अपवाद संचालकों के लिए दायरा एक मार्कर क्लॉज से प्रारंभिक होता है (try या भाषा का ब्लॉक स्टार्टर जैसे begin) और पहले प्रबंधक क्लॉज की प्रारंभमें समाप्त होता है (catch, except, rescue). कई प्रबंधक क्लॉज अनुसरण कर सकते हैं, और प्रत्येक निर्दिष्ट कर सकता है कि यह किस अपवाद प्रकार को संभालता है और अपवाद वस्तु के लिए किस नाम का उपयोग करता है। सामान्य भिन्नता के रूप में, कुछ भाषाएँ एकल प्रबंधक खंड का उपयोग करती हैं, जो आंतरिक रूप से अपवाद के वर्ग से संबंधित है।

इसके अतिरिक्त सामान्य एक संबंधित खंड है (finally या ensure) जिसे निष्पादित किया जाता है चाहे कोई अपवाद हुआ हो या नहीं, सामान्यतः अपवाद-प्रबंधन ब्लॉक के शरीर के अंदर प्राप्त संसाधनों को जारी करने के लिए। विशेष रूप से, C++ यह निर्माण प्रदान नहीं करता है, इसके अतिरिक्त संसाधन अधिग्रहण प्रारंभ है (RAII) विधि की पक्षसमर्थन करता है जो डिस्ट्रक्टर (कंप्यूटर प्रोग्रामिंग) का उपयोग करके संसाधनों को मुक्त करता है। वेस्टली वीमर और जॉर्ज नेकुला द्वारा 2008 के एक पेपर के अनुसार, वाक्य रचना try...finally जावा में ब्लॉक सॉफ्टवेयर दोषों के लिए एक योगदान कारक है। जब एक विधि को 3-5 संसाधनों के अधिग्रहण और रिलीज को संभालने की आवश्यकता होती है, तो प्रोग्रामर स्पष्ट रूप से पठनीयता संबंधी चिंताओं के कारण पर्याप्त ब्लॉकों को नेस्ट करने के लिए तैयार नहीं होते हैं, तब भी जब यह एक सही समाधान होगा। सिंगल का उपयोग करना संभव है try...finally कई संसाधनों के साथ काम करते समय भी ब्लॉक करें, किन्तु इसके लिए प्रहरी मूल्यों के सही उपयोग की आवश्यकता होती है, जो इस प्रकार की समस्या के लिए बग का एक अन्य सामान्य स्रोत है।

पायथन और रूबी भी एक खंड की अनुमति देते हैं (else) जिसका उपयोग प्रबंधक के सीमा के अंत तक पहुंचने से पहले कोई अपवाद नहीं होने पर किया जाता है।

अपने पूरे में, अपवाद प्रबंधन कोड इस तरह दिख सकता है (जावा (प्रोग्रामिंग भाषा) में - स्यूडोकोड की तरह):

try {
    line = console.readLine();

    if (line.length() == 0) {
        throw new EmptyLineException("The line read from console was empty!");
    }

    console.printLine("Hello %s!" % line);
}
catch (EmptyLineException e) {
    console.printLine("Hello!");
}
catch (Exception e) {
    console.printLine("Error: " + e.message());
}
else {
    console.printLine("The program ran successfully.");
}
finally {
    console.printLine("The program is now terminating.");
}

C में ट्राई-कैच अपवाद प्रबंधन नहीं है, किन्तु त्रुटि जाँच के लिए वापसी कोड का उपयोग करता है। समुच्चय जम्प.एच |setjmp और longjmpमैक्रोज़ के माध्यम से ट्राइ-कैच प्रबंधन को प्रयुक्त करने के लिए मानक पुस्तकालय फलन का उपयोग किया जा सकता है।

पर्ल 5 उपयोग करता है die के लिए throw और eval {} if ($@) {} ट्राई-कैच के लिए। इसमें सीपीएएन मॉड्यूल हैं जो ट्राइ-कैच सेमेन्टिक्स प्रदान करते हैं।

समाप्ति और बहाली शब्दार्थ

जब एक अपवाद प्रक्षेपण जाता है, तो प्रोग्राम फलन कॉल के कॉल स्टैक के माध्यम से वापस खोजता है जब तक कि एक अपवाद प्रबंधक नहीं मिल जाता। जैसे ही यह खोज आगे बढ़ती है, कुछ भाषाओं में स्टैक को खोलने की आवश्यकता होती है। अर्थात यदि फलन f, एक प्रबंधक युक्त H अपवाद के लिए E, फलन पुकारता है g, जो बदले में फलन को पुकारता है h, और एक अपवाद E में होता है h, फिर कार्य करता है h और g समाप्त किया जा सकता है, और H में f सम्हाल लेंगे E. इसे समाप्ति शब्दार्थ कहा जाता है।

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

किसी भी निर्णय के पक्ष में सैद्धांतिक और रचना तर्क हैं। 1989-1991 में C++ मानकीकरण चर्चाओं के परिणामस्वरूप C++ में समापन अर्थ विज्ञान का उपयोग करने का एक निश्चित निर्णय हुआ। बज़्ने स्ट्रॉस्ट्रुप एक महत्वपूर्ण डेटा बिंदु के रूप में जेम्स जी. मिशेल की एक प्रस्तुति का हवाला देते हैं:

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

“समाप्ति को फिर से शुरू करने से अधिक पसंद किया जाता है; यह कोई राय की बात नहीं है बल्कि वर्षों के अनुभव की बात है। बहाली मोहक है, लेकिन मान्य नहीं है।

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

बहाली के साथ अपवाद-प्रबंधन भाषाओं में या स्थिति प्रणाली के साथ कॉमन लिस्प, पीएल/आई, डायलन, R_(प्रोग्रामिंग_भाषा) सम्मिलित हैं। और लघु वार्ता। चूंकि, अधिकांश नई प्रोग्रामिंग भाषाएँ C ++ का अनुसरण करती हैं और समाप्ति शब्दार्थ का उपयोग करती हैं।

अपवाद प्रबंधन कार्यान्वयन

प्रोग्रामिंग भाषाओं में अपवाद प्रबंधन के कार्यान्वयन में सामान्यतः एक कोड जनरेटर और एक कंपाइलर के साथ रनटाइम प्रणाली दोनों से उचित मात्रा में समर्थन सम्मिलित होता है। (यह C++ में अपवाद प्रबंधन का जोड़ था जिसने मूल C++ कंपाइलर, सामने के उपयोगी जीवनकाल को समाप्त कर दिया।) दो योजनाएँ सबसे आम हैं। पहला,गतिशील पंजीकरण, कोड उत्पन्न करता है जो अपवाद प्रबंधन के संदर्भ में प्रोग्राम स्थिति के बारे में संरचनाओं को लगातार अद्यतन करता है। सामान्यतः, यह कॉल स्टैक में एक नया तत्व जोड़ता है जो जानता है कि उस फ्रेम से जुड़े कार्य या विधि के लिए कौन से प्रबंधक उपलब्ध हैं; यदि कोई अपवाद जाता है, तो विन्यास में एक सूचक कार्यविधि को उचित प्रबंधक कोड पर निर्देशित करता है। यह दृष्टिकोण अंतरिक्ष के स्थितियों में कॉम्पैक्ट है, किन्तु फ्रेम प्रविष्टि और निकास पर निष्पादन ओवरहेड जोड़ता है। यह सामान्यतः कई एडीए कार्यान्वयनों में उपयोग किया जाता था, उदाहरण के लिए, जहां कई अन्य भाषा सुविधाओं के लिए जटिल पीढ़ी और कार्यविधि समर्थन की पहले से ही आवश्यकता थी। माइक्रोसॉफ्ट का 32-बिट संरचित अपवाद प्रबंधन (एसईएच) एक अलग अपवाद स्टैक के साथ इस दृष्टिकोण का उपयोग करता है। डायनेमिक पंजीकरण, परिभाषित करने के लिए अधिक सरल होने के कारण, शुद्धता के प्रमाण के लिए उत्तरदायी होता है।

दूसरी योजना, और कई उत्पादन-गुणवत्ता वाले C++ कंपाइलरों और 64-बिट माइक्रोसॉफ्ट संरचित अपवाद प्रबंधन में प्रयुक्त की गई, एक टेबल-संचालित दृष्टिकोण है| यह संकलन समय और लिंक समय पर स्थिर तालिकाएँ बनाता है जो अपवाद प्रबंधन के संबंध में कार्यक्रम गणक की प्रोग्राम स्थिति से संबंधित होती हैं। फिर, यदि कोई अपवाद प्रछेपड है, तो कार्यविधि प्रणाली तालिकाओं में वर्तमान निर्देश स्थान को देखता है और यह निर्धारित करता है कि कौन से प्रबंधक चल रहे हैं और क्या करने की आवश्यकता होती है। यह दृष्टिकोण उस स्थितियों के लिए कार्यकारी ओवरहेड को कम करता है जहां अपवाद नहीं प्रछेपड है। यह कुछ स्थान की कीमत पर होता है, किन्तु इस स्थान को केवल-पढ़ने के लिए, विशेष-उद्देश्य वाले डेटा अनुभागों में आवंटित किया जा सकता है जो वास्तव में एक अपवाद फेंके जाने तक लोड या स्थानांतरित नहीं होते हैं। एक अपवाद को संभालने के लिए कोड का स्थान (स्मृति में) मेमोरी के उस क्षेत्र के अंदर (या उसके पास भी) स्थित होना चाहिए| जहां बाकी फलन का कोड संग्रहीत होता है। तो यदि एक अपवाद फेंक दिया जाता है तो एक प्रदर्शन हिट - मोटे तौर पर एक फलन कॉल के बराबर - हो सकता है यदि आवश्यक अपवाद प्रबंधन कोड को लोड/कैश करने की आवश्यकता हो। चूंकि, इस योजना की न्यूनतम प्रदर्शन निवेश है यदि कोई अपवाद नहीं फेंका जाता है। चूँकि C++ में अपवादों को असाधारण (अर्थात असामान्य/दुर्लभ) घटनाएँ माना जाता है, वाक्यांश शून्य-निवेश अपवाद कभी-कभी c ++ में अपवाद प्रबंधन का वर्णन करने के लिए प्रयोग किया जाता है। रनटाइम प्रकार की पहचान (आरटीटीआई) की तरह, अपवाद C++ के शून्य-ओवरहेड सिद्धांत का पालन नहीं कर सकते हैं क्योंकि रन-टाइम पर अपवाद प्रबंधन को प्रयुक्त करने के लिए एक गैर की आवश्यकता होती है। लुकअप सारिणी के लिए शून्य मात्रा में मेमोरी। इस कारण से, अपवाद प्रबंधन (और आरटीटीआई) को कई C++ कंपाइलर्स में अक्षम किया जा सकता है, जो कि बहुत सीमित स्मृति वाले प्रणाली के लिए उपयोगी हो सकता है(जैसे अंतः स्थापित प्रणाली)। कड़ी सुरक्षा प्राप्त करने के स्थितियों में यह दूसरा दृष्टिकोण भी उत्तम है.

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

अनुबंध द्वारा रचना के आधार पर अपवाद प्रबंधन

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

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

वस्तु-उन्मुख सॉफ्टवेयर निर्माण में बर्ट्रेंड मेयर द्वारा प्रस्तुत किया गया सुरक्षित अपवाद प्रबंधन सिद्धांत तब मानता है कि अपवाद होने पर प्रक्रिया केवल दो सार्थक विधि से प्रतिक्रिया कर सकता है:

• विफलता, या संगठित आतंक: नित्य वस्तु की स्थिति को अपरिवर्तनीय (यह संगठित भाग है) को फिर से स्थापित करके ठीक करता है, और फिर विफल रहता है (घबड़ाहट), इसके कॉलर में एक अपवाद को ट्रिगर करता है (जिससे असामान्य घटना को अनदेखा न किया जा सके) .
• पुन: प्रयास करें: दिनचर्या एल्गोरिथम को फिर से आज़माती है, सामान्यतः कुछ मूल्यों को बदलने के बाद जिससे अगले प्रयास में सफल होने का उत्तम मौका मिले सकता है।

विशेष रूप से, केवल एक अपवाद को नज़रअंदाज़ करने की अनुमति नहीं है; एक ब्लॉक को या तो फिर से प्रयास करना चाहिए और सफलतापूर्वक पूरा करना चाहिए, या इसके कॉलर को अपवाद का प्रचार करना चाहिए।

एफिल वाक्य - विन्यास में व्यक्त एक उदाहरण यहां दिया गया है। यह एक दिनचर्या मानता है send_fast सामान्यतः संदेश भेजने का उत्तम विधि होता है, किन्तु यह विफल हो सकता है, अपवाद को चालू कर सकता है; यदि ऐसा है, तो अगला एल्गोरिथम उपयोग करता है send_slow, जो कम बार विफल होगा। यदि send_slow विफल रहता है, दिनचर्या send पूरी तरह से असफल होना चाहिए, जिससे कॉलर को अपवाद मिल सकता है।

send (m: MESSAGE) is
  -- Send m through fast link, if possible, otherwise through slow link.
local
  tried_fast, tried_slow: BOOLEAN
do
  if tried_fast then
     tried_slow := True
     send_slow (m)
  else
     tried_fast := True
     send_fast (m)
  end
rescue
  if not tried_slow then
     retry
  end
end

प्रारंभ में बूलियन स्थानीय चरों को False में आवाक्षरित किया जाता है। यदि send_fast विफल रहता है, शरीर (do खंड) को फिर से निष्पादित किया जाएगा, जिसके निष्पादन का कारण होगा send_slow. यदि यह निष्पादन send_slow विफल रहता है, rescue खंड नहीं के साथ अंत तक निष्पादित होगा retry (नहीं else फाइनल में खंड if), जिससे नियमित निष्पादन पूरी तरह से विफल हो जाता है।

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

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

अनकहा अपवाद

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

यदि एक अपवाद को फेंक दिया जाता है और पकड़ा नहीं जाता है (परिचालन में, एक अपवाद तब फेंका जाता है जब कोई प्रयुक्त प्रबंधक निर्दिष्ट नहीं होता है), न आया हुआ अपवाद कार्यविधि द्वारा नियंत्रित किया जाता है; ऐसा करने वाली दिनचर्या कहलाती है अनकहा अपवाद संचालक. सबसे आम डिफ़ॉल्ट व्यवहार प्रोग्राम को समाप्त करना और कंसोल पर एक त्रुटि संदेश छपाई करना है, सामान्यतः डिबग जानकारी जैसे कि अपवाद का एक स्ट्रिंग प्रतिनिधित्व और स्टैक ट्रेस सम्मिलित है। यह अधिकांशतः एक शीर्ष-स्तरीय (एप्लिकेशन-स्तर) प्रबंधक (उदाहरण के लिए एक घटना पाश में) होने से बचा जाता है जो अपवादों को कार्यविधि तक पहुंचने से पहले पकड़ लेता है।

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

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

यह डिफ़ॉल्ट बेजोड़ अपवाद प्रबंधक ओवरराइड किया जा सकता है, या तो विश्व स्तर पर या प्रति-कड़ी, उदाहरण के लिए वैकल्पिक लॉगिंग या अनकैप्ड अपवादों की एंड-यूज़र सूची प्रदान करने के लिए, या उन कड़ी्स को फिर से प्रारंभिक करने के लिए जो अनकवर्ड अपवाद के कारण समाप्त हो जाते हैं। उदाहरण के लिए, जावा में यह सिंगल कड़ी के लिए किया जाता है Thread.setUncaughtExceptionHandler और विश्व स्तर पर के माध्यम से Thread.setDefaultUncaughtExceptionHandler; पायथन में यह संशोधित करके किया जाता है sys.excepthook.

चेक किए गए अपवाद

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

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

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

एंडर्स हेल्सबर्ग ने चेक किए गए अपवादों के साथ दो चिंताओं का वर्णन किया है:

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

इनके आसपास काम करने के लिए, हेजल्सबर्ग का कहना है कि प्रोग्रामर एक का उपयोग करके सुविधा को दरकिनार करने का सहारा लेते हैं throws Exception घोषणा। एक और धोखा a का उपयोग करना है try { ... } catch (Exception e) {} हैंडलर।इसे पोकेमोन के कैचफ्रेज़ गॉट्टा कैच 'एम ऑल! . जावा शिक्षण सामग्री कैच-ऑल अपवाद प्रबंधन को हतोत्साहित करता है क्योंकि यह उन अपवादों को पकड़ सकता है जिनके लिए प्रबंधक का इरादा नहीं था। फिर भी एक और हतोत्साहित करने वाली चाल सभी अपवादों को उपवर्ग बनाना है RuntimeException. एक प्रोत्साहित समाधान कैच-ऑल प्रबंधक या थ्रो क्लॉज का उपयोग करना है, किन्तु सामान्य सुपरक्लास के अतिरिक्त सभी संभावित फेंके गए अपवादों के एक विशिष्ट सुपरक्लास (कंप्यूटर विज्ञान) के साथ Exception. एक अन्य प्रोत्साहित समाधान अपवाद प्रकारों को परिभाषित और घोषित करना है जो तथाकथित विधि के अमूर्त स्तर के लिए उपयुक्त हैं और अपवाद श्रृंखलन का उपयोग करके निम्न स्तर के अपवादों को इन प्रकारों में मैप करें।

समान तंत्र

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

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

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

अपवादों की गतिशील जाँच

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

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

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

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

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

प्रोग्रामिंग भाषा सामान्यतः अतुल्यकालिक अपवाद प्रबंधन से बचती हैं या प्रतिबंधित करती हैं, उदाहरण के लिए C ++ सिग्नल प्रबंधक से अपवादों को बढ़ाने से मना करती है, और जावा ने अपने कड़ीअंत अपवाद के उपयोग को हटा दिया है जिसका उपयोग एक कड़ी को दूसरे को रोकने के लिए किया गया था। अन्य विशेषता एक अर्ध-अतुल्यकालिक तंत्र है जो केवल कार्यक्रम के कुछ संचालन के समय एक अतुल्यकालिक अपवाद उठाता है। उदाहरण के लिए जावा का Thread.interrupt() केवल कड़ी को प्रभावित करता है जब कड़ी InterruptedExceptionको फेंकने वाले ऑपरेशन को कॉल करता है. समान पॉज़िक्स pthread_cancel एपीआई में दौड़ की स्थिति है जो इसे सुरक्षित रूप से उपयोग करना असंभव बनाती है।

स्थिति प्रणाली

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

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

निरंतर अपवाद

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

एक उदाहरण पीएल/आई में 'आखरीपन्ना ' स्थिति है; ऑन इकाई अगले पेज के लिए पेज अनुयान लाइन और हेडर लाइन लिख सकती है, फिर अवरोधित कोड के निष्पादन को फिर से प्रारंभिक करने के लिए गिर सकती है।

पॉलिसी से अलग मैकेनिज्म को फिर से प्रारंभिक करता है

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

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

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

आलोचना

सॉफ़्टवेयर में अपवाद प्रबंधन को अधिकांशतः ठीक से नियंत्रित नहीं किया जाता है, विशेष रूप से जब अपवादों के कई स्रोत होते हैं; जावा कोड की 5 मिलियन लाइनों के डेटा प्रवाह विश्लेषण में 1300 से अधिक अपवाद प्रबंधन दोष पाए गए थे।

दूसरों (1999-2004) के कई पूर्व अध्ययनों और अपने स्वयं के परिणामों का हवाला देते हुए, वीमर और नेकुला ने लिखा कि अपवादों के साथ एक महत्वपूर्ण समस्या यह है कि वे छिपे हुए नियंत्रण-प्रवाह पथ बनाते हैं जो प्रोग्रामर के लिए तर्क करना कठिनाई होता है। जबकि कोशिश पकड़ने के अंत में वैचारिक रूप से सरल है, भाषा विनिर्देश [गोस्लिंग एट अल। 1996] और इसके आधिकारिक अंग्रेजी विवरण में नेस्टेड "यदि" के चार स्तरों की आवश्यकता है। संक्षेप में, इसमें बड़ी संख्या में कोने के स्थितियों होते हैं जिन्हें प्रोग्रामर अधिकांशतः अनदेखा कर देते हैं।

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

1980 में टोनी होरे ने एडा (प्रोग्रामिंग भाषा) वर्णन इस प्रकार किया था "सुविधाओं और सांकेतिक सम्मेलन उनमें से कई अनावश्यक हैं, और उनमें से कुछ, जैसे अपवाद प्रबंधन, यहां तक ​​​​कि खतरनाक भी है । [...] इस भाषा को इसकी वर्तमान स्थिति में उन अनुप्रयोगों में उपयोग करने की अनुमति न दें जहाँ विश्वसनीयता महत्वपूर्ण है [...]। प्रोग्रामिंग भाषा की त्रुटि के परिणामस्वरूप भटकने वाला अगला रॉकेट शुक्र की हानिरहित यात्रा पर एक खोजपूर्ण अंतरिक्ष रॉकेट नहीं हो सकता है: यह हमारे अपने शहरों में से एक पर विस्फोट करने वाला परमाणु बम हो सकता है।

द गो (प्रोग्रामिंग भाषा ) डेवलपर्स का मानना ​​​​है कि कोशिश-पकड़-अंतिम मुहावरा नियंत्रण प्रवाह को अवरोधित करता है, और अपवाद जैसे panic/recover तंत्र कि प्रारंभ कि । recover() catch से अलग है इसे केवल फलन में defer कोड ब्लॉक के भीतर से ही बुलाया जा सकता है, इसलिए प्रबंधक केवल क्लीन-अप कर सकता है और फलन के वापसी मान को बदल सकता है, और फलन के अंदर एक इच्छानुसार बिंदु पर नियंत्रण वापस नहीं कर सकता। defer }}ब्लॉक करता स्वयं finally खंड के समान कार्य करता है।।

यूआई पदानुक्रमों में अपवाद प्रबंधन

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

उदाहरण के लिए, वीयूई में, एक घटक प्रयुक्त करके त्रुटियों को पकड़ लेता है | errorCaptured

Vue.component('parent', {
    template: '<div><slot></slot></div>',
    errorCaptured: (err, vm, info) => alert('An error occurred');
})
Vue.component('child', {
    template: '<div>{{ cause_error() }}</div>'
})

मार्कअप में इस तरह उपयोग किए जाने पर:

<parent>
    <child></child>
</parent>

चाइल्ड घटक द्वारा उत्पन्न त्रुटि को पैरेंट घटक द्वारा पकड़ा और नियंत्रित किया जाता है।

यह भी देखें

• स्वचालित अपवाद प्रबंधन
• अपवाद सुरक्षा
• जारी
• रक्षात्मक प्रोग्रामिंग
• तिगुना दोष
• विकल्प प्रकार और परिणाम प्रकार, अपवाद के बिना कार्यात्मक प्रोग्रामिंग में त्रुटियों को संभालने के वैकल्पिक विधि
• आंकड़ा मान्यीकरण

संदर्भ

• Black, Andrew P. (January 1982). Exception handling: The case against (PDF) (PhD). University of Oxford. CiteSeerX 10.1.1.94.5554. OCLC 123311492.
• Gabriel, Richard P.; Steele, Guy L. (2008). A Pattern of Language Evolution (PDF). LISP50: Celebrating the 50th Anniversary of Lisp. pp. 1–10. doi:10.1145/1529966.1529967. ISBN 978-1-60558-383-9.
• Goodenough, John B. (1975a). Structured exception handling. Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages - POPL '75. pp. 204–224. doi:10.1145/512976.512997.
• Goodenough, John B. (1975). "Exception handling: Issues and a proposed notation" (PDF). Communications of the ACM. 18 (12): 683–696. CiteSeerX 10.1.1.122.7791. doi:10.1145/361227.361230. S2CID 12935051.
• Levin, Roy (June 1977). Program Structures for Exceptional Condition Handling (PDF) (PhD). Carnegie-Mellon University. DTIC ADA043449. Archived (PDF) from the original on December 22, 2021.
• Stroustrup, Bjarne (1994). The design and evolution of C++ (1st ed.). Reading, Mass.: Addison-Wesley. ISBN 0-201-54330-3.
• White, Jon L (May 1979). NIL - A Perspective (PDF). Proceedings of the 1979 Macsyma User's Conference.

बाहरी संबंध

• A Crash Course on the Depths of Win32 Structured Exception Handling by Matt Pietrek - Microsoft Systems Journal (1997)
• Article "C++ Exception Handling" by Christophe de Dinechin
• Article "Exceptional practices" by Brian Goetz
• Article "Object Oriented Exception Handling in Perl" by Arun Udaya Shankar
• Article "Programming with Exceptions in C++" by Kyle Loudon
• Article "Unchecked Exceptions - The Controversy"
• Conference slides Floating-Point Exception-Handling policies (pdf p. 46) by William Kahan
• Descriptions from Portland Pattern Repository
• Does Java Need Checked Exceptions?