एक्सेप्शन हेंडलिंग: Difference between revisions

Latest revision as of 06:39, 19 October 2023

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

परिभाषा

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

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

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

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

इतिहास

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

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

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

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

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

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

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

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

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

आईईईई 754 मानक असाधारण स्थितियों पर उपयोगकर्ता द्वारा प्रदत्त अपवाद-प्रबंधन प्रक्रिया को कॉल करने के संदर्भ में प्रग्रहण शब्द का उपयोग करता है, और यह मानक की एक वैकल्पिक विशेषता है। मानक इसके लिए कई उपयोग परिदृश्यों की पक्षसमर्थन करता है, जिसमें हटाने योग्य विलक्षणता को संक्षिप्त रूप से संभालने के लिए मान के गैर-डिफ़ॉल्ट पूर्व-प्रतिस्थापन के कार्यान्वयन के बाद फिर से प्रारंभिक करना सम्मिलित है।Cite error: Invalid <ref> tag; invalid names, e.g. too many^[18]

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

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

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

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

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

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

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

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

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

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

पायथन और रूबी भी एक खंड की अनुमति देते हैं (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मैक्रोज़ के माध्यम से ट्राइ-कैच प्रबंधन को प्रयुक्त करने के लिए मानक पुस्तकालय फलन का उपयोग किया जा सकता है।^[25]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अनकहा अपवाद

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

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

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

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

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

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

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

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

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

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

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

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

समान तंत्र

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

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

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

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

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

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

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

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

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

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

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

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

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

निरंतर अपवाद

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

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

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

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

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

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

आलोचना

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

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

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

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

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

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

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

उदाहरण के लिए, वीयूई में, एक घटक प्रयुक्त करके त्रुटियों को पकड़ लेता है | 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>

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

यह भी देखें

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

↑ In, e.g., PL/I, a normal exit from an exception handler unwinds the stack.
↑ There is "zero [processing] cost" only if no exception is throw (although there will be a memory cost since memory is needed for the lookup table). There is a (potentially significant) cost if an exception is thrown (that is, if throw is executed). Implementing exception handling may also limit the possible compiler optimizations that may be performed.

संदर्भ

↑ ^1.0 ^1.1 Cristian, Flaviu (1980). "Exception Handling and Software Fault Tolerance". Proc. 10th Int. Symp. On Fault Tolerant Computing (FTCS-25 reprint ed.) (6): 531–540. CiteSeerX 10.1.1.116.8736. doi:10.1109/TC.1982.1676035. OCLC 1029229019. S2CID 18345469.
↑ Goodenough 1975b, pp. 683–684.
↑ Goodenough 1975b, p. 684.
↑ Black 1982, pp. 13–15.
↑ ^5.0 ^5.1 Lang, Jun; Stewart, David B. (March 1998). "A study of the applicability of existing exception-handling techniques to component-based real-time software technology". ACM Transactions on Programming Languages and Systems. 20 (2): 276. CiteSeerX 10.1.1.33.3400. doi:10.1145/276393.276395. S2CID 18875882. Perhaps the most common form of exception-handling method used by software programmers is the "return-code" technique that was popularized as part of C and UNIX.
↑ Levin 1977, p. 5.
↑ ^7.0 ^7.1 Liskov, B.H.; Snyder, A. (November 1979). "Exception Handling in CLU" (PDF). IEEE Transactions on Software Engineering. SE-5 (6): 546–558. doi:10.1109/TSE.1979.230191. S2CID 15506879. Retrieved 19 December 2021.
↑ Levin 1977, p. 4.
↑ ^9.0 ^9.1 ^9.2 ^9.3 ^9.4 Kiniry, J. R. (2006). "Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application". Advanced Topics in Exception Handling Techniques (PDF). Lecture Notes in Computer Science. Vol. 4119. pp. 288–300. doi:10.1007/11818502_16. ISBN 978-3-540-37443-5.
↑ Smotherman, Mark. "Interrupts". Retrieved 4 January 2022.
↑ McCarthy, John (12 February 1979). "History of Lisp". www-formal.stanford.edu. Retrieved 13 January 2022.
↑ McCarthy, John; Levin, Michael I.; Abrahams, Paul W.; Edwards, Daniel J.; Hart, Timothy P. (14 July 1961). LISP 1.5 programmer's manual (PDF). Retrieved 13 January 2022.
↑ "The ON Statement" (PDF). IBM System/360 Operating System, PL/I Language Specifications (PDF). IBM. July 1966. p. 120. C28-6571-3.
↑ Gabriel & Steele 2008, p. 3.
↑ White 1979, p. 194.
↑ ^16.0 ^16.1 Stroustrup 1994, p. 392.
↑ Hyde, Randall. "Art of Assembly: Chapter Seventeen". www.plantation-productions.com. Retrieved 22 December 2021.
↑ Hauser, John R. (March 1996). "Handling floating-point exceptions in numeric programs". ACM Transactions on Programming Languages and Systems. 18 (2): 139–174. doi:10.1145/227699.227701. S2CID 9820157.
↑ Cite error: Invalid <ref> tag; no text was provided for refs named grail
↑ "Built-in Exceptions — Python 3.10.4 documentation". docs.python.org. Retrieved 17 May 2022.
↑ "Stroustrup: C++ Style and Technique FAQ". www.stroustrup.com. Archived from the original on 2 February 2018. Retrieved 5 May 2018.
↑ Bloch, Joshua (2008). "Item 57: Use exceptions only for exceptional situations". Effective Java (Second ed.). Addison-Wesley. p. 241. ISBN 978-0-321-35668-0.
↑ Stroustrup, Bjarne. "C++ Style and Technique FAQ". www.stroustrup.com. Retrieved 12 January 2022.
↑ ^24.0 ^24.1 ^24.2 ^24.3 Weimer, W; Necula, G.C. (2008). "Exceptional Situations and Program Reliability" (PDF). ACM Transactions on Programming Languages and Systems. Vol. 30, no. 2. Archived (PDF) from the original on 2015-09-23.
↑ Roberts, Eric S. (21 March 1989). "Implementing Exceptions in C" (PDF). DEC Systems Research Center. SRC-RR-40. Retrieved 4 January 2022. {{cite journal}}: Cite journal requires |journal= (help)
↑ Christiansen, Tom; Torkington, Nathan (2003). "10.12. Handling Exceptions". Perl cookbook (2nd ed.). Beijing: O'Reilly. ISBN 0-596-00313-7.
↑ Stroustrup 1994, 16.6 Exception Handling: Resumption vs. Termination, pp. 390–393.
↑ "R: Condition Handling and Recovery". search.r-project.org. Retrieved 2022-12-05.
↑ Scott Meyers, The Most Important C++ Software...Ever Archived 2011-04-28 at the Wayback Machine, 2006
↑ D. Cameron, P. Faust, D. Lenkov, M. Mehta, "A portable implementation of C++ exception handling", Proceedings of the C++ Conference (August 1992) USENIX.
↑ Peter Kleissner (February 14, 2009). "Windows Exception Handling - Peter Kleissner". Archived from the original on October 14, 2013. Retrieved 2009-11-21., Compiler based Structured Exception Handling section
↑ Graham Hutton, Joel Wright, "Compiling Exceptions Correctly Archived 2014-09-11 at the Wayback Machine". Proceedings of the 7th International Conference on Mathematics of Program Construction, 2004.
↑ Lajoie, Josée (March–April 1994). "Exception handling – Supporting the runtime mechanism". C++ Report. 6 (3).
↑ ^34.0 ^34.1 Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN Notices. 33 (8): 40–47. doi:10.1145/286385.286390. S2CID 1522664.
↑ "Modern C++ best practices for exceptions and error handling". Microsoft. 8 March 2021. Retrieved 21 March 2022.
↑ ^36.0 ^36.1 Stroustrup, Bjarne (18 November 2019). "C++ exceptions and alternatives" (PDF). Retrieved 23 March 2022.
↑ M. Hof, H. Mössenböck, P. Pirkelbauer, "Zero-Overhead Exception Handling Using Metaprogramming Archived 2016-03-03 at the Wayback Machine", Proceedings SOFSEM'97, November 1997, Lecture Notes in Computer Science 1338, pp. 423-431.
↑ All Exceptions Are Handled, Jim Wilcox, "All Exceptions Are Handled". Archived from the original on 2015-03-18. Retrieved 2014-12-08.
↑ ^39.0 ^39.1 ^39.2 Mac Developer Library, "Uncaught Exceptions Archived 2016-03-04 at the Wayback Machine"
↑ MSDN, AppDomain.UnhandledException Event Archived 2016-03-04 at the Wayback Machine
↑ The Python Tutorial, "8. Errors and Exceptions Archived 2015-09-01 at the Wayback Machine"
↑ "Java Practices -> Provide an uncaught exception handler". www.javapractices.com. Archived from the original on 9 September 2016. Retrieved 5 May 2018.
↑ PyMOTW (Python Module Of The Week), "Exception Handling Archived 2015-09-15 at the Wayback Machine"
↑ "Google Answers: The origin of checked exceptions". Archived from the original on 2011-08-06. Retrieved 2011-12-15.
↑ Java Language Specification, chapter 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 Archived 2006-12-08 at the Wayback Machine
↑ Mössenböck, Hanspeter (2002-03-25). "Advanced C#: Variable Number of Parameters" (PDF). Institut für Systemsoftware, Johannes Kepler Universität Linz, Fachbereich Informatik. p. 32. Archived (PDF) from the original on 2011-09-20. Retrieved 2011-08-05.
↑ ^47.0 ^47.1 ^47.2 Eckel, Bruce (2006). Thinking in Java (4th ed.). Upper Saddle River, NJ: Prentice Hall. pp. 347–348. ISBN 0-13-187248-6.
↑ Gunnerson, Eric (9 November 2000). "C# and exception specifications". Archived from the original on 1 January 2006.
↑ ^49.0 ^49.1 Bill Venners; Bruce Eckel (August 18, 2003). "The Trouble with Checked Exceptions: A Conversation with Anders Hejlsberg, Part II". Retrieved 4 January 2022.
↑ Juneau, Josh (31 May 2017). Java 9 Recipes: A Problem-Solution Approach (in English). Apress. p. 226. ISBN 978-1-4842-1976-8.
↑ "Advantages of Exceptions (The Java™ Tutorials : Essential Classes : Exceptions)". Download.oracle.com. Archived from the original on 2011-10-26. Retrieved 2011-12-15.
↑ "Unchecked Exceptions – The Controversy (The Java™ Tutorials : Essential Classes : Exceptions)". Download.oracle.com. Archived from the original on 2011-11-17. Retrieved 2011-12-15.
↑ Bloch 2001:178 Bloch, Joshua (2001). Effective Java Programming Language Guide. Addison-Wesley Professional. ISBN 978-0-201-31005-4.
↑ ^54.0 ^54.1 "Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?". Mindview.net. Archived from the original on 2002-04-05. Retrieved 2011-12-15.
↑ "Modula-3 - Procedure Types". .cs.columbia.edu. 1995-03-08. Archived from the original on 2008-05-09. Retrieved 2011-12-15.
↑ ^56.0 ^56.1 Bjarne Stroustrup, The C++ Programming Language Third Edition, Addison Wesley, 1997. ISBN 0-201-88954-4. pp. 375-380.
↑ Reeves, J.W. (July 1996). "Ten Guidelines for Exception Specifications". C++ Report. 8 (7).
↑ Sutter, Herb (3 March 2010). "Trip Report: March 2010 ISO C++ Standards Meeting". Archived from the original on 23 March 2010. Retrieved 24 March 2010.
↑ "OcamlExc - An uncaught exceptions analyzer for Objective Caml". Caml.inria.fr. Archived from the original on 2011-08-06. Retrieved 2011-12-15.
↑ "Asynchronous Exceptions in Haskell - Marlow, Jones, Moran (ResearchIndex)". Citeseer.ist.psu.edu. Archived from the original on 2011-02-23. Retrieved 2011-12-15.
↑ Freund, Stephen N.; Mitchell, Mark P. "Safe Asynchronous Exceptions For Python" (PDF). Retrieved 4 January 2022. {{cite journal}}: Cite journal requires |journal= (help)
↑ "Java Thread Primitive Deprecation". Java.sun.com. Archived from the original on 2009-04-26. Retrieved 2011-12-15.
↑ "Interrupts (The Java™ Tutorials > Essential Java Classes > Concurrency)". docs.oracle.com. Retrieved 5 January 2022.
↑ Felker, Rich. "Thread cancellation and resource leaks". ewontfix.com. Retrieved 5 January 2022.
↑ What Conditions (Exceptions) are Really About (2008-03-24). "What Conditions (Exceptions) are Really About". Danweinreb.org. Archived from the original on February 1, 2013. Retrieved 2014-09-18.
↑ "Condition System Concepts". Franz.com. 2009-07-21. Archived from the original on 2007-06-28. Retrieved 2011-12-15.
↑ C.A.R. Hoare. "The Emperor's Old Clothes". 1980 Turing Award Lecture
↑ "Frequently Asked Questions". Archived from the original on 2017-05-03. Retrieved 2017-04-27. We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.
↑ Panic And Recover Archived 2013-10-24 at the Wayback Machine, Go wiki
↑ Bendersky, Eli (8 August 2018). "On the uses and misuses of panics in Go". Eli Bendersky's website. Retrieved 5 January 2022. The specific limitation is that recover can only be called in a defer code block, which cannot return control to an arbitrary point, but can only do clean-ups and tweak the function's return values.
↑ "Error Boundaries". React. Retrieved 2018-12-10.
↑ "Vue.js API". Vue.js. Retrieved 2018-12-10.
↑ "Error handling with Vue.js". CatchJS. Retrieved 2018-12-10.

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?

[27] In, e.g., PL/I, a normal exit from an exception handler unwinds the stack.

[37] There is "zero [processing] cost" only if no exception is throw (although there will be a memory cost since memory is needed for the lookup table). There is a (potentially significant) cost if an exception is thrown (that is, if throw is executed). Implementing exception handling may also limit the possible compiler optimizations that may be performed.

[Cristian-1] 1.0 ^1.1 Cristian, Flaviu (1980). "Exception Handling and Software Fault Tolerance". Proc. 10th Int. Symp. On Fault Tolerant Computing (FTCS-25 reprint ed.) (6): 531–540. CiteSeerX 10.1.1.116.8736. doi:10.1109/TC.1982.1676035. OCLC 1029229019. S2CID 18345469.

[FOOTNOTEGoodenough1975b683–684-2] Goodenough 1975b, pp. 683–684.

[FOOTNOTEGoodenough1975b684-3] Goodenough 1975b, p. 684.

[FOOTNOTEBlack198213–15-4] Black 1982, pp. 13–15.

[Lang-5] 5.0 ^5.1 Lang, Jun; Stewart, David B. (March 1998). "A study of the applicability of existing exception-handling techniques to component-based real-time software technology". ACM Transactions on Programming Languages and Systems. 20 (2): 276. CiteSeerX 10.1.1.33.3400. doi:10.1145/276393.276395. S2CID 18875882. Perhaps the most common form of exception-handling method used by software programmers is the "return-code" technique that was popularized as part of C and UNIX.

[FOOTNOTELevin19775-6] Levin 1977, p. 5.

[CLU-7] 7.0 ^7.1 Liskov, B.H.; Snyder, A. (November 1979). "Exception Handling in CLU" (PDF). IEEE Transactions on Software Engineering. SE-5 (6): 546–558. doi:10.1109/TSE.1979.230191. S2CID 15506879. Retrieved 19 December 2021.

[FOOTNOTELevin19774-8] Levin 1977, p. 4.

[Kiniry-9] 9.0 ^9.1 ^9.2 ^9.3 ^9.4 Kiniry, J. R. (2006). "Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application". Advanced Topics in Exception Handling Techniques (PDF). Lecture Notes in Computer Science. Vol. 4119. pp. 288–300. doi:10.1007/11818502_16. ISBN 978-3-540-37443-5.

[Smotherman-10] Smotherman, Mark. "Interrupts". Retrieved 4 January 2022.

[11] McCarthy, John (12 February 1979). "History of Lisp". www-formal.stanford.edu. Retrieved 13 January 2022.

[12] McCarthy, John; Levin, Michael I.; Abrahams, Paul W.; Edwards, Daniel J.; Hart, Timothy P. (14 July 1961). LISP 1.5 programmer's manual (PDF). Retrieved 13 January 2022.

[13] "The ON Statement" (PDF). IBM System/360 Operating System, PL/I Language Specifications (PDF). IBM. July 1966. p. 120. C28-6571-3.

[FOOTNOTEGabrielSteele20083-14] Gabriel & Steele 2008, p. 3.

[FOOTNOTEWhite1979194-15] White 1979, p. 194.

[FOOTNOTEStroustrup1994392-16] 16.0 ^16.1 Stroustrup 1994, p. 392.

[17] Hyde, Randall. "Art of Assembly: Chapter Seventeen". www.plantation-productions.com. Retrieved 22 December 2021.

[18] Hauser, John R. (March 1996). "Handling floating-point exceptions in numeric programs". ACM Transactions on Programming Languages and Systems. 18 (2): 139–174. doi:10.1145/227699.227701. S2CID 9820157.

[grail-19] Cite error: Invalid <ref> tag; no text was provided for refs named grail

[20] "Built-in Exceptions — Python 3.10.4 documentation". docs.python.org. Retrieved 17 May 2022.

[21] "Stroustrup: C++ Style and Technique FAQ". www.stroustrup.com. Archived from the original on 2 February 2018. Retrieved 5 May 2018.

[EffectiveJava-22] Bloch, Joshua (2008). "Item 57: Use exceptions only for exceptional situations". Effective Java (Second ed.). Addison-Wesley. p. 241. ISBN 978-0-321-35668-0.

[23] Stroustrup, Bjarne. "C++ Style and Technique FAQ". www.stroustrup.com. Retrieved 12 January 2022.

[toplas2008-24] 24.0 ^24.1 ^24.2 ^24.3 Weimer, W; Necula, G.C. (2008). "Exceptional Situations and Program Reliability" (PDF). ACM Transactions on Programming Languages and Systems. Vol. 30, no. 2. Archived (PDF) from the original on 2015-09-23.

[25] Roberts, Eric S. (21 March 1989). "Implementing Exceptions in C" (PDF). DEC Systems Research Center. SRC-RR-40. Retrieved 4 January 2022. {{cite journal}}: Cite journal requires |journal= (help)

[26] Christiansen, Tom; Torkington, Nathan (2003). "10.12. Handling Exceptions". Perl cookbook (2nd ed.). Beijing: O'Reilly. ISBN 0-596-00313-7.

[FOOTNOTEStroustrup199416.6_Exception_Handling:_Resumption_vs._Termination,_pp._390–393-28] Stroustrup 1994, 16.6 Exception Handling: Resumption vs. Termination, pp. 390–393.

[29] "R: Condition Handling and Recovery". search.r-project.org. Retrieved 2022-12-05.

[30] Scott Meyers, The Most Important C++ Software...Ever Archived 2011-04-28 at the Wayback Machine, 2006

[31] D. Cameron, P. Faust, D. Lenkov, M. Mehta, "A portable implementation of C++ exception handling", Proceedings of the C++ Conference (August 1992) USENIX.

[32] Peter Kleissner (February 14, 2009). "Windows Exception Handling - Peter Kleissner". Archived from the original on October 14, 2013. Retrieved 2009-11-21., Compiler based Structured Exception Handling section

[33] Graham Hutton, Joel Wright, "Compiling Exceptions Correctly Archived 2014-09-11 at the Wayback Machine". Proceedings of the 7th International Conference on Mathematics of Program Construction, 2004.

[34] Lajoie, Josée (March–April 1994). "Exception handling – Supporting the runtime mechanism". C++ Report. 6 (3).

[cppeh-35] 34.0 ^34.1 Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN Notices. 33 (8): 40–47. doi:10.1145/286385.286390. S2CID 1522664.

[MiscrosoftDocsExceptions-36] "Modern C++ best practices for exceptions and error handling". Microsoft. 8 March 2021. Retrieved 21 March 2022.

[StroustrupExceptions2019-38] 36.0 ^36.1 Stroustrup, Bjarne (18 November 2019). "C++ exceptions and alternatives" (PDF). Retrieved 23 March 2022.

[39] M. Hof, H. Mössenböck, P. Pirkelbauer, "Zero-Overhead Exception Handling Using Metaprogramming Archived 2016-03-03 at the Wayback Machine", Proceedings SOFSEM'97, November 1997, Lecture Notes in Computer Science 1338, pp. 423-431.

[40] All Exceptions Are Handled, Jim Wilcox, "All Exceptions Are Handled". Archived from the original on 2015-03-18. Retrieved 2014-12-08.

[cocoa-41] 39.0 ^39.1 ^39.2 Mac Developer Library, "Uncaught Exceptions Archived 2016-03-04 at the Wayback Machine"

[42] MSDN, AppDomain.UnhandledException Event Archived 2016-03-04 at the Wayback Machine

[43] The Python Tutorial, "8. Errors and Exceptions Archived 2015-09-01 at the Wayback Machine"

[44] "Java Practices -> Provide an uncaught exception handler". www.javapractices.com. Archived from the original on 9 September 2016. Retrieved 5 May 2018.

[pmotw-45] PyMOTW (Python Module Of The Week), "Exception Handling Archived 2015-09-15 at the Wayback Machine"

[46] "Google Answers: The origin of checked exceptions". Archived from the original on 2011-08-06. Retrieved 2011-12-15.

[47] Java Language Specification, chapter 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 Archived 2006-12-08 at the Wayback Machine

[48] Mössenböck, Hanspeter (2002-03-25). "Advanced C#: Variable Number of Parameters" (PDF). Institut für Systemsoftware, Johannes Kepler Universität Linz, Fachbereich Informatik. p. 32. Archived (PDF) from the original on 2011-09-20. Retrieved 2011-08-05.

[Eckel-49] 47.0 ^47.1 ^47.2 Eckel, Bruce (2006). Thinking in Java (4th ed.). Upper Saddle River, NJ: Prentice Hall. pp. 347–348. ISBN 0-13-187248-6.

[50] Gunnerson, Eric (9 November 2000). "C# and exception specifications". Archived from the original on 1 January 2006.

[Trouble-51] 49.0 ^49.1 Bill Venners; Bruce Eckel (August 18, 2003). "The Trouble with Checked Exceptions: A Conversation with Anders Hejlsberg, Part II". Retrieved 4 January 2022.

[52] Juneau, Josh (31 May 2017). Java 9 Recipes: A Problem-Solution Approach (in English). Apress. p. 226. ISBN 978-1-4842-1976-8.

[53] "Advantages of Exceptions (The Java™ Tutorials : Essential Classes : Exceptions)". Download.oracle.com. Archived from the original on 2011-10-26. Retrieved 2011-12-15.

[54] "Unchecked Exceptions – The Controversy (The Java™ Tutorials : Essential Classes : Exceptions)". Download.oracle.com. Archived from the original on 2011-11-17. Retrieved 2011-12-15.

[55] Bloch 2001:178 Bloch, Joshua (2001). Effective Java Programming Language Guide. Addison-Wesley Professional. ISBN 978-0-201-31005-4.

[Mindview-56] 54.0 ^54.1 "Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?". Mindview.net. Archived from the original on 2002-04-05. Retrieved 2011-12-15.

[57] "Modula-3 - Procedure Types". .cs.columbia.edu. 1995-03-08. Archived from the original on 2008-05-09. Retrieved 2011-12-15.

[bjarne-exc-58] 56.0 ^56.1 Bjarne Stroustrup, The C++ Programming Language Third Edition, Addison Wesley, 1997. ISBN 0-201-88954-4. pp. 375-380.

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

[60] Sutter, Herb (3 March 2010). "Trip Report: March 2010 ISO C++ Standards Meeting". Archived from the original on 23 March 2010. Retrieved 24 March 2010.

[61] "OcamlExc - An uncaught exceptions analyzer for Objective Caml". Caml.inria.fr. Archived from the original on 2011-08-06. Retrieved 2011-12-15.

[62] "Asynchronous Exceptions in Haskell - Marlow, Jones, Moran (ResearchIndex)". Citeseer.ist.psu.edu. Archived from the original on 2011-02-23. Retrieved 2011-12-15.

[63] Freund, Stephen N.; Mitchell, Mark P. "Safe Asynchronous Exceptions For Python" (PDF). Retrieved 4 January 2022. {{cite journal}}: Cite journal requires |journal= (help)

[64] "Java Thread Primitive Deprecation". Java.sun.com. Archived from the original on 2009-04-26. Retrieved 2011-12-15.

[65] "Interrupts (The Java™ Tutorials > Essential Java Classes > Concurrency)". docs.oracle.com. Retrieved 5 January 2022.

[66] Felker, Rich. "Thread cancellation and resource leaks". ewontfix.com. Retrieved 5 January 2022.

[67] What Conditions (Exceptions) are Really About (2008-03-24). "What Conditions (Exceptions) are Really About". Danweinreb.org. Archived from the original on February 1, 2013. Retrieved 2014-09-18.

[68] "Condition System Concepts". Franz.com. 2009-07-21. Archived from the original on 2007-06-28. Retrieved 2011-12-15.

[69] C.A.R. Hoare. "The Emperor's Old Clothes". 1980 Turing Award Lecture

[70] "Frequently Asked Questions". Archived from the original on 2017-05-03. Retrieved 2017-04-27. We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

[71] Panic And Recover Archived 2013-10-24 at the Wayback Machine, Go wiki

[72] Bendersky, Eli (8 August 2018). "On the uses and misuses of panics in Go". Eli Bendersky's website. Retrieved 5 January 2022. The specific limitation is that recover can only be called in a defer code block, which cannot return control to an arbitrary point, but can only do clean-ups and tweak the function's return values.

[73] "Error Boundaries". React. Retrieved 2018-12-10.

[74] "Vue.js API". Vue.js. Retrieved 2018-12-10.

[75] "Error handling with Vue.js". CatchJS. Retrieved 2018-12-10.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[note 1]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[note 2]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

Anonymous

Search

एक्सेप्शन हेंडलिंग: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 06:39, 19 October 2023

Contents

परिभाषा

इतिहास

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

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

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

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

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

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

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

अनकहा अपवाद

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

समान तंत्र

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

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

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

निरंतर अपवाद

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

आलोचना

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

यह भी देखें

टिप्पणियाँ

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 1: / Line 1: @@
 {{Short description|Programming language construct for special conditions}}
-{{Redirect-distinguish|Error handling|Error detection and correction}}
+[[कम्प्यूटिंग]] और [[कंप्यूटर प्रोग्राम|कंप्यूटर]] प्रोग्रामिंग में, अपवाद प्रबंधन एक कंप्यूटर प्रोग्राम के [[निष्पादन (कंप्यूटिंग)]] के समय 'अपवाद की घटना का उत्तर देने की प्रक्रिया है - विशेष प्रसंस्करण की आवश्यकता वाली असामान्य या असाधारण स्थिति है। सामान्यतः, एक अपवाद निष्पादन के सामान्य प्रवाह को तोड़ता है और पूर्व-पंजीकृत अपवाद प्रबंधक को निष्पादित करता है; यह कैसे किया जाता है इसका विवरण इस बात पर निर्भर करता है कि यह [[कंप्यूटर हार्डवेयर]] या [[सॉफ़्टवेयर]] अपवाद है और सॉफ़्टवेयर अपवाद कैसे कार्यान्वित किया जाता है। अपवाद प्रबंधन, यदि प्रदान की जाती है, तो विशेष [[प्रोग्रामिंग भाषा]] निर्माण, हार्डवेयर तंत्र जैसे [[बाधा डालना]], या [[ऑपरेटिंग सिस्टम|ऑपरेटिंग प्रणाली]] (ओएस) [[अंतःप्रक्रम संचार]] (आईपीसी) सुविधाएं जैसे संकेत (आईपीसी) द्वारा सुविधा प्रदान की जाती है। कुछ अपवादों, विशेष रूप से हार्डवेयर वाले, को इतनी सभ्यतः से संभाला जा सकता है कि निष्पादन फिर से प्रारंभिक हो सकता है जहां इसे अवरोधित किया गया था।
-{{About|computing|knowledge|fact checking|and|problem solving}}
-[[कम्प्यूटिंग]] और [<nowiki/>[[कंप्यूटर प्रोग्राम|कंप्यूटर]] प्रोग्रामिंग] में, अपवाद प्रबंधन एक कंप्यूटर प्रोग्राम के [[निष्पादन (कंप्यूटिंग)]] के समय 'अपवाद की घटना का उत्तर देने की प्रक्रिया है - विशेष प्रसंस्करण की आवश्यकता वाली असामान्य या असाधारण स्थिति। सामान्यतः, एक अपवाद निष्पादन के सामान्य प्रवाह को तोड़ता है और एक पूर्व-पंजीकृत अपवाद हैंडलर को निष्पादित करता है; यह कैसे किया जाता है इसका विवरण इस बात पर निर्भर करता है कि यह [[कंप्यूटर हार्डवेयर]] या [[सॉफ़्टवेयर]] अपवाद है और सॉफ़्टवेयर अपवाद कैसे कार्यान्वित किया जाता है। अपवाद हैंडलिंग, यदि प्रदान की जाती है, तो विशेष [[प्रोग्रामिंग भाषा]] निर्माण, हार्डवेयर तंत्र जैसे [[बाधा डालना]], या [[ऑपरेटिंग सिस्टम|ऑपरेटिंग प्रणाली]] (OS) [[अंतःप्रक्रम संचार]] (IPC) सुविधाएं जैसे सिग्नल (IPC) द्वारा सुविधा प्रदान की जाती है। कुछ अपवादों, विशेष रूप से हार्डवेयर वाले, को इतनी शालीनता से संभाला जा सकता है कि निष्पादन फिर से प्रारंभिक हो सकता है जहां इसे बाधित किया गया था।
 == परिभाषा ==
-एक अपवाद की परिभाषा इस अवलोकन पर आधारित है कि प्रत्येक [[सबरूटीन]] की एक पूर्व शर्त होती है, परिस्थितियों का एक समुच्चय जिसके लिए यह सामान्य रूप से समाप्त हो जाएगा।<ref name=Cristian>{{cite journal |last1=Cristian |first1=Flaviu |title=Exception Handling and Software Fault Tolerance |journal=Proc. 10th Int. Symp. On Fault Tolerant Computing|date=1980 |issue=6 |pages=531–540 |doi=10.1109/TC.1982.1676035|citeseerx=10.1.1.116.8736|s2cid=18345469 |oclc=1029229019|edition=FTCS-25 reprint}}</ref> एक अपवाद हैंडलिंग तंत्र प्रक्रिया को अपवाद बढ़ाने की अनुमति देता है{{sfn|Goodenough|1975b|pp=683-684}} यदि इस पूर्व शर्त का उल्लंघन किया जाता है,<ref name=Cristian/>उदाहरण के लिए यदि प्रक्रिया को तर्कों के असामान्य समुच्चय पर बुलाया गया है। अपवाद हैंडलिंग तंत्र तब अपवाद को संभालता है।{{sfn|Goodenough|1975b|p=684}}
+एक अपवाद की परिभाषा इस अवलोकन पर आधारित है कि प्रत्येक [[सबरूटीन|प्रक्रिया]] की एक पूर्व स्थिति होती है, परिस्थितियों का एक समूह जिसके लिए यह सामान्य रूप से समाप्त हो जाता है ।<ref name=Cristian>{{cite journal |last1=Cristian |first1=Flaviu |title=Exception Handling and Software Fault Tolerance |journal=Proc. 10th Int. Symp. On Fault Tolerant Computing|date=1980 |issue=6 |pages=531–540 |doi=10.1109/TC.1982.1676035|citeseerx=10.1.1.116.8736|s2cid=18345469 |oclc=1029229019|edition=FTCS-25 reprint}}</ref> एक अपवाद प्रबंधन तंत्र प्रक्रिया को अपवाद बढ़ाने की अनुमति देता है{{sfn|Goodenough|1975b|pp=683-684}} यदि इस पूर्व स्थिति का उल्लंघन किया जाता है,<ref name=Cristian/> तो उदाहरण के लिए यदि प्रक्रिया को तर्कों के असामान्य समूह पर कहा गया है। अपवाद प्रबंधन तंत्र उस समय अपवाद को संभालता है।{{sfn|Goodenough|1975b|p=684}}
-पूर्व शर्त और अपवाद की परिभाषा [[आत्मीयता]] है। सामान्य परिस्थितियों का समुच्चय प्रोग्रामर द्वारा पूरी तरह से परिभाषित किया गया है, उदा। प्रोग्रामर शून्य से विभाजन को अपरिभाषित मान सकता है, इसलिए एक अपवाद, या कुछ व्यवहार तैयार कर सकता है जैसे कि शून्य या एक विशेष शून्य विभाजित मान (अपवादों की आवश्यकता को रोकना)।{{sfn|Black|1982|pp=13-15}} सामान्य अपवादों में एक अमान्य तर्क (जैसे मान फ़ंक्शन के डोमेन के बाहर है), एक अनुपलब्ध संसाधन (जैसे एक अनुपलब्ध फ़ाइल, एक हार्ड डिस्क त्रुटि, या आउट-ऑफ़-मेमोरी त्रुटियां) सम्मिलित हैं, या यह कि रूटीन ने सामान्य का पता लगाया है स्थिति जिसके लिए विशेष हैंडलिंग की आवश्यकता होती है, उदाहरण के लिए, ध्यान, फ़ाइल का अंत।
-एक्सेप्शन हैंडलिंग सेमीप्रेडिकेट समस्या को हल करती है, जिसमें तंत्र सामान्य रिटर्न वैल्यू को गलत से अलग करता है। जिन भाषाओं में अंतर्निहित अपवाद प्रबंधन नहीं होता है जैसे सी, रूटीन को त्रुटि को किसी अन्य विधि से संकेत देने की आवश्यकता होती है, जैसे कि सामान्य [[वापसी कोड]] और इरनो पैटर्न।<ref name=Lang/>व्यापक दृष्टिकोण से, त्रुटियों को अपवादों का उचित उपसमुच्चय माना जा सकता है,{{sfn|Levin|1977|p=5}} और स्पष्ट त्रुटि तंत्र जैसे errno को अपवाद हैंडलिंग के (वर्बोज़) रूपों पर विचार किया जा सकता है।<ref name=Lang>{{cite journal |last1=Lang |first1=Jun |last2=Stewart |first2=David B. |title=A study of the applicability of existing exception-handling techniques to component-based real-time software technology |journal=ACM Transactions on Programming Languages and Systems |date=March 1998 |volume=20 |issue=2 |pages=276 |doi=10.1145/276393.276395|citeseerx=10.1.1.33.3400|s2cid=18875882 |quote=Perhaps the most common form of exception-handling method used by software programmers is the “return-code” technique that was popularized as part of C and UNIX.}}</ref> शब्द अपवाद को त्रुटि के लिए प्राथमिकता दी जाती है क्योंकि इसका अर्थ यह नहीं है कि कुछ भी गलत है - एक प्रक्रिया या प्रोग्रामर द्वारा त्रुटि के रूप में देखी जाने वाली स्थिति को दूसरे द्वारा इस तरह नहीं देखा जा सकता है। यहां तक कि शब्द अपवाद भी भ्रामक हो सकता है क्योंकि इसका :wikt:Exception outlier इंगित करता है कि कुछ दुर्लभ या असामान्य हुआ है, जब वास्तव में अपवाद उठाना कार्यक्रम में एक सामान्य और सामान्य स्थिति हो सकती है।<ref name="CLU"/>उदाहरण के लिए, मान लीजिए कि एक [[साहचर्य सरणी]] के लिए एक लुकअप फ़ंक्शन अपवाद फेंकता है यदि कुंजी में कोई मान संबद्ध नहीं है। संदर्भ के आधार पर, यह कुंजी अनुपस्थित अपवाद सफल लुकअप की तुलना में बहुत अधिक बार हो सकता है।{{sfn|Levin|1977|p=4}}
+पूर्व स्थिति और अपवाद की परिभाषा [[आत्मीयता]] है। सामान्य परिस्थितियों का समुच्चय प्रोग्रामर द्वारा पूरी तरह से परिभाषित किया गया है, उदा। प्रोग्रामर शून्य से विभाजन को अपरिभाषित मान सकता है, इसलिए एक अपवाद, या कुछ गतिविधि तैयार कर सकता है जैसे कि शून्य या एक विशेष शून्य विभाजित मान (अपवादों की आवश्यकता को रोकना)।{{sfn|Black|1982|pp=13-15}} सामान्य अपवादों में एक अमान्य तर्क (जैसे मान फलन के कार्यक्षेत्र के बाहर है), एक अनुपलब्ध संसाधन (जैसे एक अनउपलब्ध फ़ाइल, एक हार्ड डिस्क त्रुटि, या मेमोरी त्रुटियां की तरह) सम्मिलित हैं, या यह कि प्रक्रिया ने सामान्य का पता लगाया जाता है स्थिति जिसके लिए विशेष प्रबंधन की आवश्यकता होती है, उदाहरण के लिए, ध्यान, फ़ाइल का अंत देख सकते है ।
+अपवाद प्रबंधन अर्धविधेय समस्या को हल करती है, जिसमें तंत्र सामान्य वापसी मान को त्रुटिपूर्ण से अलग करता है। जिन भाषाओं में अंतर्निहित अपवाद प्रबंधन नहीं होता है जैसे C, प्रक्रिया को त्रुटि को किसी अन्य विधि से संकेत देने की आवश्यकता होती है, जैसे कि सामान्य [[वापसी कोड]] और इरनो स्वरूप ।<ref name="Lang" /> व्यापक दृष्टिकोण से, त्रुटियों को अपवादों का उचित उपसमुच्चय माना जा सकता है,{{sfn|Levin|1977|p=5}} और स्पष्ट त्रुटि तंत्र जैसे इरनो को अपवाद प्रबंधन के (वाचाल) रूपों पर विचार किया जा सकता है।<ref name="Lang">{{cite journal |last1=Lang |first1=Jun |last2=Stewart |first2=David B. |title=A study of the applicability of existing exception-handling techniques to component-based real-time software technology |journal=ACM Transactions on Programming Languages and Systems |date=March 1998 |volume=20 |issue=2 |pages=276 |doi=10.1145/276393.276395|citeseerx=10.1.1.33.3400|s2cid=18875882 |quote=Perhaps the most common form of exception-handling method used by software programmers is the “return-code” technique that was popularized as part of C and UNIX.}}</ref> शब्द अपवाद को त्रुटि के लिए प्राथमिकता दी जाती है क्योंकि इसका अर्थ यह नहीं है कि कुछ भी गलत है - एक प्रक्रिया या प्रोग्रामर द्वारा त्रुटि के रूप में देखी जाने वाली स्थिति को दूसरे द्वारा इस तरह नहीं देखा जा सकता है। यहां तक कि शब्द अपवाद भी भ्रामक हो सकता है क्योंकि "ग़ैर" का इसका विशिष्ट अर्थ इंगित करता है कि कुछ दुर्लभ या असामान्य हुआ है, जब वास्तव में अपवाद उठाना कार्यक्रम में एक सामान्य और सामान्य स्थिति हो सकती है।<ref name="CLU" /> उदाहरण के लिए, मान लीजिए कि एक [[साहचर्य सरणी]] के लिए लुकअप फलन अपवाद फेंकता है यदि कुंजी में कोई मान संबद्ध नहीं है। संदर्भ के आधार पर, यह कुंजी अनुपस्थित अपवाद सफल लुकअप की तुलना में बहुत अधिक बार हो सकता है।{{sfn|Levin|1977|p=4}}
+अपवादों के सीमा और उपयोग पर एक बड़ा प्रभाव सामाजिक दबाव है, अर्थात उपयोग के उदाहरण, सामान्यतः मुख्य पुस्तकालयों में पाए जाते हैं, और तकनीकी पुस्तकों, पत्रिका लेखों और ऑनलाइन चर्चा मंचों एक संगठन के कोड मानकों में कोड उदाहरण है "।<ref name="Kiniry" />
-अपवादों के सीमा और उपयोग पर एक बड़ा प्रभाव सामाजिक दबाव है, अर्थात उपयोग के उदाहरण, सामान्यतः मुख्य पुस्तकालयों में पाए जाते हैं, और तकनीकी पुस्तकों, पत्रिका लेखों और ऑनलाइन चर्चा मंचों में और संगठन के कोड मानकों में कोड उदाहरण।<ref name="Kiniry" />
 == इतिहास ==
-पहला हार्डवेयर अपवाद संचालन 1951 से [[UNIVAC I]] में पाया गया। अंकगणितीय अतिप्रवाह ने पता 0 पर दो निर्देशों को निष्पादित किया, जो नियंत्रण को स्थानांतरित कर सकता था या परिणाम को ठीक कर सकता था।<ref name=Smotherman>{{cite web |last1=Smotherman |first1=Mark |title=Interrupts |url=https://people.cs.clemson.edu/~mark/interrupts.html |access-date=4 January 2022}}</ref>
+पहला हार्डवेयर अपवाद संचालन 1951 से [[UNIVAC I|यूनीवैक]] में पाया गया। अंकगणितीय अतिप्रवाह ने पता 0 पर दो निर्देशों को निष्पादित किया, जो नियंत्रण को स्थानांतरित कर सकता था या परिणाम को ठीक कर सकता था।<ref name=Smotherman>{{cite web |last1=Smotherman |first1=Mark |title=Interrupts |url=https://people.cs.clemson.edu/~mark/interrupts.html |access-date=4 January 2022}}</ref>
-सॉफ्टवेयर अपवाद हैंडलिंग 1960 और 1970 के दशक में विकसित हुआ। एलआईएसपी 1.5 (1958-1961)<ref>{{cite web |last1=McCarthy |first1=John |title=History of Lisp |url=http://www-formal.stanford.edu/jmc/history/lisp/node1.html |website=www-formal.stanford.edu |access-date=13 January 2022 |date=12 February 1979}}</ref> द्वारा उठाए जाने वाले अपवादों की अनुमति दी <code>ERROR</code> स्यूडो-फलन  , दुभाषिया या संकलक द्वारा उठाए गए त्रुटियों के समान। द्वारा अपवाद पकड़े गए <code>ERRORSET</code> कीवर्ड, जो वापस आ गया <code>NIL</code> त्रुटि के मामले में, कार्यक्रम को समाप्त करने या डीबगर में प्रवेश करने के अतिरिक्त।<ref>{{cite book|
+सॉफ्टवेयर अपवाद प्रबंधन 1960 और 1970 के दशक में विकसित हुआ। एलआईएसपी 1.5 (1958-1961)<ref>{{cite web |last1=McCarthy |first1=John |title=History of Lisp |url=http://www-formal.stanford.edu/jmc/history/lisp/node1.html |website=www-formal.stanford.edu |access-date=13 January 2022 |date=12 February 1979}}</ref> <code>ERROR</code> स्यूडो-फलन द्वारा उठाए जाने वाले अपवादों की अनुमति देता है, ठीक उसी तरह जैसे इंटरप्रेटर या कंपाइलर द्वारा की गई त्रुटियां है।<code>ERRORSET</code> कुंजीशब्द, अपवाद पकड़े गए जो प्रोग्राम को समाप्त करने या डीबगर में प्रवेश करने के अतिरिक्त त्रुटि के स्थितियों में <code>NIL</code> लौटाते हैं।<ref>{{cite book|
 first1=John|last1=McCarthy|first2=Michael I.|last2=Levin|first3=Paul W.|last3=Abrahams|first4=Daniel J.|last4=Edwards|first5=Timothy P.|last5=Hart
 |title=LISP 1.5 programmer's manual |date=14 July 1961 |url=http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual-1961.07.14.pdf#page=58 |access-date=13 January 2022}}</ref>
-पीएल/आई या ऑन-यूनिट्स और एक्सेप्शन हैंडलिंग|पीएल/आई ने 1964 के आसपास अपवाद हैंडलिंग का अपना रूप प्रस्तुत किया, जिससे इंटरप्ट्स को ऑन यूनिट्स के साथ हैंडल किया जा सके।<ref>{{cite manual
+पीएल/आई ने 1964 के आसपास अपवाद प्रबंधन का अपना रूप प्रस्तुत किया जाता है, जिससे बीच के इकाइयों पर नियंत्रित किया जा सके।<ref>{{cite manual
   | title       = IBM System/360 Operating System, PL/I Language Specifications
   | id          = C28-6571-3
@@ Line 32: / Line 32: @@
   }}
 </ref>
-[[मैकलिस्प]] ने देखा कि <code>ERRSET</code> और <code>ERR</code> न केवल त्रुटि बढ़ाने के लिए उपयोग किया गया, बल्कि गैर-स्थानीय नियंत्रण प्रवाह के लिए, और इस प्रकार दो नए कीवर्ड जोड़े गए, <code>CATCH</code> और <code>THROW</code> (जून 1972)।{{sfn|Gabriel|Steele|2008|p=3}} सफाई व्यवहार जिसे अब सामान्यतः अंत में कहा जाता है, को NIL (प्रोग्रामिंग लैंग्वेज) (LISP का नया कार्यान्वयन) में 1970 के दशक के मध्य में प्रस्तुत किया गया था <code>UNWIND-PROTECT</code>.{{sfn|White|1979|p=194}} यह तब [[सामान्य लिस्प]] द्वारा अपनाया गया था। इसके समकालीन था <code>dynamic-wind</code> स्कीम में, जिसने क्लोजर में अपवादों को संभाला। स्ट्रक्चर्ड एक्सेप्शन हैंडलिंग पर पहले पेपर थे {{harvtxt|Goodenough|1975a}} और {{harvtxt|Goodenough|1975b}}.{{sfn|Stroustrup|1994|p=392}} बाद में 1980 के दशक से कई प्रोग्रामिंग भाषाओं द्वारा एक्सेप्शन हैंडलिंग को व्यापक रूप से अपनाया गया।
+[[मैकलिस्प]] ने देखा कि <code>ERRSET</code> और <code>ERR</code> न केवल त्रुटि बढ़ाने के लिए उपयोग किया गया था ], किंतु गैर-स्थानीय नियंत्रण प्रवाह के लिए भी किया गया था, और इस प्रकार दो नए कुंजीशब्द जोड़े गए, <code>CATCH</code> और <code>THROW</code> (जून 1972)।{{sfn|Gabriel|Steele|2008|p=3}} सफाई व्यवहार जिसे अब सामान्यतः अंत में कहा जाता है, को एनआईएल (प्रोग्रामिंग भाषा) (लिस्प का नया कार्यान्वयन) में 1970 के दशक के मध्य में प्रस्तुत किया गया था <code>UNWIND-PROTECT</code>.{{sfn|White|1979|p=194}} यह तब [[सामान्य लिस्प]] द्वारा अपनाया गया था। इसके समकालीन था <code>dynamic-wind</code> स्कीम में, जिसने क्लोजर में अपवादों को संभाला। स्ट्रक्चर्ड अपवाद प्रबंधन पर पहले पेपर थे {{harvtxt|Goodenough|1975a}} और {{harvtxt|Goodenough|1975b}}.{{sfn|Stroustrup|1994|p=392}} बाद में 1980 के दशक से कई प्रोग्रामिंग भाषाओं द्वारा अपवाद प्रबंधन को व्यापक रूप से अपनाया गया है।
 == हार्डवेयर अपवाद ==
 {{Main|Interrupt}}
-हार्डवेयर के संबंध में अपवाद के स्पष्ट अर्थ के बारे में कोई स्पष्ट सहमति नहीं है।<ref>{{cite web |last1=Hyde |first1=Randall |title=Art of Assembly: Chapter Seventeen |url=https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |website=www.plantation-productions.com |access-date=22 December 2021}}</ref> कार्यान्वयन के दृष्टिकोण से, इसे एक बाधा के रूप में नियंत्रित किया जाता है: प्रोसेसर वर्तमान प्रोग्राम के निष्पादन को रोकता है, उस अपवाद या बाधा की स्थिति के लिए [[इंटरप्ट वेक्टर तालिका]] में [[इंटरप्ट हैंडलर]] को देखता है, स्थिति को बचाता है, और नियंत्रण स्विच करता है।
+हार्डवेयर के संबंध में अपवाद के स्पष्ट अर्थ के बारे में कोई स्पष्ट सहमति नहीं है।<ref>{{cite web |last1=Hyde |first1=Randall |title=Art of Assembly: Chapter Seventeen |url=https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |website=www.plantation-productions.com |access-date=22 December 2021}}</ref> कार्यान्वयन के दृष्टिकोण से, इसे बाधा के रूप में नियंत्रित किया जाता है: प्रोसेसर वर्तमान प्रोग्राम के निष्पादन को रोकता है, उस अपवाद या बाधा की स्थिति के लिए [[इंटरप्ट वेक्टर तालिका]] में इंटरप्ट प्रबंधन को देखता है, स्थिति को बचाता है, और नियंत्रण बदल सकता है।
-== [[IEEE 754]] फ़्लोटिंग-पॉइंट अपवाद ==
-IEEE 754 फ़्लोटिंग-पॉइंट अंकगणित में अपवाद हैंडलिंग या असाधारण स्थितियोंं से निपटना|फ़्लोटिंग-पॉइंट मानक सामान्य रूप से असाधारण स्थितियों को संदर्भित करता है और एक अपवाद को एक घटना के रूप में परिभाषित करता है जो तब होता है जब कुछ विशेष ऑपरेंड पर एक ऑपरेशन का कोई परिणाम नहीं होता है जो हर उचित अनुप्रयोग के लिए उपयुक्त होता है . वह ऑपरेशन डिफ़ॉल्ट या, यदि स्पष्ट रूप से अनुरोध किया गया हो, एक भाषा-परिभाषित वैकल्पिक हैंडलिंग द्वारा एक या अधिक अपवादों को संकेत दे सकता है।
-डिफ़ॉल्ट रूप से, एक IEEE 754 अपवाद फिर से प्रारंभिक किया जा सकता है और विभिन्न अपवादों के लिए पूर्वनिर्धारित मान को प्रतिस्थापित करके नियंत्रित किया जाता है, उदा। शून्य अपवाद से विभाजित करने के लिए अनंतता, और फ़्लोटिंग-पॉइंट अंकगणित प्रदान करना  या  असाधारण स्थितियोंं से निपटना बाद में जाँच के लिए कि क्या अपवाद हुआ (देखें C99 या IEEE 754 फ़्लोटिंग-पॉइंट समर्थन IEEE 754 अपवादों को संभालने के एक विशिष्ट उदाहरण के लिए)। स्टेटस फ्लैग के उपयोग से सक्षम एक अपवाद-हैंडलिंग शैली में सम्मिलित हैं: पहले एक तेज, प्रत्यक्ष कार्यान्वयन का उपयोग करके एक अभिव्यक्ति की गणना करना; यह जाँचना कि क्या यह स्थिति फ़्लैग का परीक्षण करके विफल हुआ है; और फिर, यदि आवश्यक हो, एक धीमे, अधिक संख्यात्मक रूप से शक्तिशाली , कार्यान्वयन को कॉल करना।{{cite journal |author1=Xiaoye Li|author1-link=Sherry Li |author2=James Demmel | title=एक्सेप्शन हैंडलिंग के माध्यम से तेज़ न्यूमेरिकल एल्गोरिदम, कंप्यूटर पर IEEE लेनदेन, 43(8)| year= 1994 | pages=983–992}}</रेफरी>
+== [[IEEE 754|आईईईई 754]] अस्थायी-पॉइंट अपवाद ==
+आईईईई 754 अस्थायी-पॉइंट मानक सामान्य रूप से असाधारण स्थितियों को संदर्भित करता है और एक अपवाद को एक घटना के रूप में परिभाषित करता है जो तब होता है जब कुछ विशेष ऑपरेंड पर एक ऑपरेशन का कोई परिणाम नहीं होता है जो हर उचित अनुप्रयोग के लिए उपयुक्त होता है . वह ऑपरेशन अभाव या, यदि स्पष्ट रूप से अनुरोध किया गया हो, एक भाषा-परिभाषित वैकल्पिक प्रबंधन द्वारा एक या अधिक अपवादों को संकेत दे सकता है।
-IEEE 754 मानक असाधारण स्थितियों पर उपयोगकर्ता द्वारा प्रदत्त अपवाद-हैंडलिंग रूटीन को कॉल करने के संदर्भ में ट्रैपिंग शब्द का उपयोग करता है, और यह मानक की एक वैकल्पिक विशेषता है। मानक इसके लिए कई उपयोग परिदृश्यों की पक्षसमर्थन करता है, जिसमें [[हटाने योग्य विलक्षणता]] को संक्षिप्त रूप से संभालने के लिए मूल्य के गैर-डिफ़ॉल्ट पूर्व-प्रतिस्थापन के कार्यान्वयन के बाद फिर से प्रारंभिक करना सम्मिलित है।<ref name= Xiaoye Li and James Demmel 1994 983–992 />
+अभाव रूप से, एक आईईईई 754 अपवाद फिर से प्रारंभिक किया जा सकता है और विभिन्न अपवादों के लिए पूर्वनिर्धारित मान को प्रतिस्थापित करके नियंत्रित किया जाता है, उदा। शून्य अपवाद से विभाजित करने के लिए अनंतता, और अस्थायी-पॉइंट अंकगणित प्रदान करना या असाधारण स्थितियोंं से निपटना बाद में जाँच के लिए कि क्या अपवाद हुआ (देखें C99 या आईईईई 754 अस्थायी-पॉइंट समर्थन आईईईई 754 अपवादों को संभालने के एक विशिष्ट उदाहरण के लिए)। स्थिति झंडे के उपयोग से सक्षम एक अपवाद-प्रबंधन शैली में सम्मिलित हैं: पहले एक तेज, प्रत्यक्ष कार्यान्वयन का उपयोग करके एक अभिव्यक्ति की गणना करना; यह जाँचना कि क्या यह स्थिति झंडे का परीक्षण करके विफल हुआ है; और फिर, यदि आवश्यक हो, एक धीमे, अधिक संख्यात्मक रूप से शक्तिशाली , कार्यान्वयन को पुकारना है।
-रेफरी नाम = कंघी बनानेवाले की रेती>{{cite web|url=http://www.cs.berkeley.edu/~wkahan/Grail.pdf|title=∞/∞ के लिए प्रतिस्थापन का प्रदर्शन|author=W.Kahan|date=July 5, 2005|url-status=live|archive-url=https://web.archive.org/web/20120310130507/http://www.cs.berkeley.edu/~wkahan/Grail.pdf|archive-date=March 10, 2012}}</रेफरी><ref>{{cite journal |last1=Hauser |first1=John R. |title=Handling floating-point exceptions in numeric programs |journal=ACM Transactions on Programming Languages and Systems |date=March 1996 |volume=18 |issue=2 |pages=139–174 |doi=10.1145/227699.227701|s2cid=9820157 }}</ref>
+आईईईई 754 मानक असाधारण स्थितियों पर उपयोगकर्ता द्वारा प्रदत्त अपवाद-प्रबंधन प्रक्रिया को कॉल करने के संदर्भ में प्रग्रहण शब्द का उपयोग करता है, और यह मानक की एक वैकल्पिक विशेषता है। मानक इसके लिए कई उपयोग परिदृश्यों की पक्षसमर्थन करता है, जिसमें [[हटाने योग्य विलक्षणता]] को संक्षिप्त रूप से संभालने के लिए मान के गैर-डिफ़ॉल्ट पूर्व-प्रतिस्थापन के कार्यान्वयन के बाद फिर से प्रारंभिक करना सम्मिलित है।<ref name= Xiaoye Li and James Demmel 1994 983–992 /><ref>{{cite journal |last1=Hauser |first1=John R. |title=Handling floating-point exceptions in numeric programs |journal=ACM Transactions on Programming Languages and Systems |date=March 1996 |volume=18 |issue=2 |pages=139–174 |doi=10.1145/227699.227701|s2cid=9820157 }}</ref>
-डिफ़ॉल्ट मान के पूर्व-प्रतिस्थापन के बाद फिर से प्रारंभिक होने का डिफ़ॉल्ट IEEE 754 अपवाद हैंडलिंग व्यवहार संख्यात्मक अपवादों पर प्रोग्राम नियंत्रण के बदलते प्रवाह में निहित कठिन परिस्थितिों से बचाता है। उदाहरण के लिए, 1996 [[क्लस्टर (अंतरिक्ष यान)]] प्रक्षेपण अंकगणितीय त्रुटि पर अभिकलन को निरस्त करने की [[एडा (प्रोग्रामिंग भाषा)]] अपवाद हैंडलिंग नीति के कारण एक विनाशकारी विस्फोट में समाप्त हो गया। [[विलियम कहाँ]] का प्रमाणित है कि डिफ़ॉल्ट IEEE 754 अपवाद प्रबंधन व्यवहार इसे रोक सकता था।<ref name="grail" />
+डिफ़ॉल्ट मान के पूर्व-प्रतिस्थापन के बाद फिर से प्रारंभिक होने का डिफ़ॉल्ट आईईईई 754 अपवाद प्रबंधन व्यवहार संख्यात्मक अपवादों पर प्रोग्राम नियंत्रण के बदलते प्रवाह में निहित कठिन परिस्थितिों से बचाता है। उदाहरण के लिए, 1996 [[क्लस्टर (अंतरिक्ष यान)]] प्रक्षेपण अंकगणितीय त्रुटि पर अभिकलन को निरस्त करने की [[एडा (प्रोग्रामिंग भाषा)]] अपवाद प्रबंधन नीति के कारण एक विनाशकारी विस्फोट में समाप्त हो गया। [[विलियम कहाँ]] का प्रमाणित है कि डिफ़ॉल्ट आईईईई 754 अपवाद प्रबंधन व्यवहार इसे रोक सकता था।<ref name="grail" />
 == प्रोग्रामिंग भाषाओं में अपवाद समर्थन ==
-सॉफ़्टवेयर अपवाद हैंडलिंग और सॉफ़्टवेयर टूल्स द्वारा प्रदान किया गया समर्थन हार्डवेयर में अपवाद हैंडलिंग द्वारा समझी जाने वाली चीज़ों से कुछ अलग है, किन्तु समान अवधारणाएँ सम्मिलित हैं। अपवाद से निपटने के लिए प्रोग्रामिंग भाषा तंत्र में, अपवाद शब्द का उपयोग सामान्यतः एक विशिष्ट अर्थ में एक असाधारण स्थिति के बारे में जानकारी संग्रहीत करने वाली डेटा संरचना को निरूपित करने के लिए किया जाता है। नियंत्रण स्थानांतरित करने या अपवाद बढ़ाने के लिए एक तंत्र को फेंक के रूप में जाना जाता है। कहा जाता है कि अपवाद फेंक दिया गया है। निष्पादन को कैच में स्थानांतरित कर दिया गया है।
+सॉफ़्टवेयर अपवाद प्रबंधन और सॉफ़्टवेयर उपकरण द्वारा प्रदान किया गया समर्थन हार्डवेयर में अपवाद प्रबंधन द्वारा समझी जाने वाली चीज़ों से कुछ अलग है, किन्तु समान अवधारणाएँ सम्मिलित हैं। अपवाद से निपटने के लिए प्रोग्रामिंग भाषा तंत्र में, अपवाद शब्द का उपयोग सामान्यतः एक विशिष्ट अर्थ में एक असाधारण स्थिति के बारे में जानकारी संग्रहीत करने वाली डेटा संरचना को निरूपित करने के लिए किया जाता है। नियंत्रण स्थानांतरित करने या अपवाद बढ़ाने के लिए एक तंत्र को प्रक्षेप के रूप में जाना जाता है। कहा जाता है कि अपवाद प्रक्षेप दिया गया है। निष्पादन को कैच में स्थानांतरित कर दिया गया है।
-अपवाद क्या है, इस बारे में उनकी धारणा में प्रोग्रामिंग भाषाएं अधिक हद तक भिन्न हैं। समकालीन भाषाओं को मोटे तौर पर दो समूहों में विभाजित किया जा सकता है:<ref name="Kiniry">{{Cite book | doi = 10.1007/11818502_16| chapter = Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application| title = Advanced Topics in Exception Handling Techniques| volume = 4119| pages = 288–300| series = Lecture Notes in Computer Science| year = 2006| last1 = Kiniry | first1 = J. R. | isbn = 978-3-540-37443-5|url=http://staffwww.dcs.shef.ac.uk/people/A.Simons/remodel/papers/ExceptionsInEiffelAndJava.pdf}}</ref>
+अपवाद क्या है, इस बारे में उनकी धारणा में प्रोग्रामिंग भाषाएं अधिक हद तक भिन्न हैं। समकालीन भाषाओं को दो समूहों में विभाजित किया जा सकता है:<ref name="Kiniry">{{Cite book | doi = 10.1007/11818502_16| chapter = Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application| title = Advanced Topics in Exception Handling Techniques| volume = 4119| pages = 288–300| series = Lecture Notes in Computer Science| year = 2006| last1 = Kiniry | first1 = J. R. | isbn = 978-3-540-37443-5|url=http://staffwww.dcs.shef.ac.uk/people/A.Simons/remodel/papers/ExceptionsInEiffelAndJava.pdf}}</ref>
-* भाषाएँ जहाँ अपवादों को प्रवाह नियंत्रण संरचनाओं के रूप में उपयोग करने के लिए डिज़ाइन किया गया है: Ada, Modula-3, ML, OCaml, PL/I, Python, और Ruby इस श्रेणी में आते हैं। उदाहरण के लिए, Iterator या Python|Python के पुनरावर्तक StopIteration अपवादों को यह संकेत देने के लिए फेंकते हैं कि पुनरावर्तक द्वारा कोई और आइटम नहीं बनाया गया है।<ref>{{cite web |title=Built-in Exceptions — Python 3.10.4 documentation |url=https://docs.python.org/3/library/exceptions.html#StopIteration |website=docs.python.org |access-date=17 May 2022}}</ref>
+* भाषाएँ जहाँ अपवादों को प्रवाह नियंत्रण संरचनाओं के रूप में उपयोग करने के लिए रचना कि गयी है: एडीए, मोडुला-3, एमएल, ओकैमल, पीएल/आई, पायथन, और रूबी इस श्रेणी में आते हैं। उदाहरण के लिए, इटेरटर या पायथन|पायथन के पुनरावर्तक बंद करो अपवादों को यह संकेत देने को प्रक्षेप कहते हैं कि पुनरावर्तक द्वारा कोई और सामान नहीं बनाया गया है।<ref>{{cite web |title=Built-in Exceptions — Python 3.10.4 documentation |url=https://docs.python.org/3/library/exceptions.html#StopIteration |website=docs.python.org |access-date=17 May 2022}}</ref>
-* भाषाएँ जहाँ अपवादों का उपयोग केवल असामान्य, अप्रत्याशित, गलत स्थितियों को संभालने के लिए किया जाता है: C++,<ref>{{cite web|url=http://www.stroustrup.com/bs_faq2.html#exceptions-what-not|title=Stroustrup: C++ Style and Technique FAQ|website=www.stroustrup.com|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20180202012417/http://www.stroustrup.com/bs_faq2.html#exceptions-what-not|archive-date=2 February 2018}}</ref> जावा,<ref name="EffectiveJava">
+* भाषाएँ जहाँ अपवादों का उपयोग केवल असामान्य, अप्रत्याशित, गलत स्थितियों को संभालने के लिए किया जाता है: C++,<ref>{{cite web|url=http://www.stroustrup.com/bs_faq2.html#exceptions-what-not|title=Stroustrup: C++ Style and Technique FAQ|website=www.stroustrup.com|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20180202012417/http://www.stroustrup.com/bs_faq2.html#exceptions-what-not|archive-date=2 February 2018}}</ref> java,<ref name="EffectiveJava">
 {{cite book
   | last = Bloch
@@ Line 69: / Line 68: @@
   | chapter-url = https://archive.org/details/effectivejava00bloc_0/page/241
   | edition = Second
-  }}</ref> सी  या , कॉमन लिस्प, एफिल और मोडुला -2।
+  }}</ref> C या , कॉमन लिस्प, एफिल और मोडुला -2।
-पीएल/मैंने गतिशील रूप से सीमा वाले अपवादों का उपयोग किया। पीएल / आई अपवाद हैंडलिंग में ऐसी घटनाएँ सम्मिलित हैं जो त्रुटियाँ नहीं हैं, उदाहरण के लिए, ध्यान, फ़ाइल का अंत, सूचीबद्ध चर का संशोधन।
+पीएल/आई ने गतिशील रूप से सीमा वाले अपवादों का उपयोग किया। पीएल/आई अपवाद प्रबंधन में ऐसी घटनाएँ सम्मिलित हैं जो त्रुटियाँ नहीं हैं, उदाहरण के लिए, ध्यान, फ़ाइल का अंत, सूचीबद्ध चर का संशोधन किया जाता है|
-=== सिंटेक्स ===
+=== वाक्य - विन्यास ===
-{{Further|Exception handling syntax}}
+{{Further|अपवाद हैंडलिंग सिंटैक्स}}
-कई कंप्यूटर भाषाओं में अपवादों और अपवाद प्रबंधन के लिए अंतर्निहित सिंटैक्टिक समर्थन है। इसमें [[ActionScript]], [[एडा प्रोग्रामिंग भाषा]], [[ब्लिट्ज मैक्स]], [[सी ++]], सी शार्प (प्रोग्रामिंग लैंग्वेज)|सी या , [[क्लोजर]], [[कोबोल]], [[डी प्रोग्रामिंग भाषा]], ईसीएमएस्क्रिप्ट, एफिल (प्रोग्रामिंग लैंग्वेज), [[जावा (प्रोग्रामिंग भाषा)]], [[एमएल प्रोग्रामिंग भाषा]], [[वस्तु पास्कल]] ( जैसे [[डेल्फी (प्रोग्रामिंग भाषा)]], [[फ़्री पास्कल]], और इसी तरह), [[पॉवरबिल्डर]], [[उद्देश्य सी]], [[OCaml]], [[पीएचपी]] (संस्करण 5 के अनुसार), पीएल/आई, पीएल/एसक्यूएल, [[प्रोलॉग]], पायथन (प्रोग्रामिंग लैंग्वेज), [[असली बुनियादी]], [[रूबी (प्रोग्रामिंग भाषा)]], [[स्काला (प्रोग्रामिंग भाषा)]], [[सही]], स्मॉलटॉक, [[टीसीएल]], [[विजुअल प्रोलॉग]] और अधिकांश .NET फ्रेमवर्क|.नेट लैंग्वेज।
+कई कंप्यूटर भाषाओं में अपवादों और अपवाद प्रबंधन के लिए अंतर्निहित वाक्य-रचना के नियमों के अनुसार समर्थन है। इसमें [[ActionScript|एक्शनस्क्रिप्ट]], [[एडा प्रोग्रामिंग भाषा|एडा]], [[ब्लिट्ज मैक्स]], [[सी ++|c++]], C शार्प (प्रोग्रामिंग भाषा)| C या , [[क्लोजर]], [[कोबोल]], [[डी प्रोग्रामिंग भाषा]], ईसीएमएस्क्रिप्ट, एफिल (प्रोग्रामिंग भाषा), [[जावा (प्रोग्रामिंग भाषा)]], [[एमएल प्रोग्रामिंग भाषा]], [[वस्तु पास्कल]] ( जैसे [[डेल्फी (प्रोग्रामिंग भाषा)]], [[फ़्री पास्कल]], और इसी तरह), [[पॉवरबिल्डर]], [[उद्देश्य सी]], [[OCaml]], [[पीएचपी]] (संस्करण 5 के अनुसार), पीएल/आई, पीएल/एसक्यूएल, [[प्रोलॉग]], पायथन (प्रोग्रामिंग भाषा), [[असली बुनियादी]], [[रूबी (प्रोग्रामिंग भाषा)]], [[स्काला (प्रोग्रामिंग भाषा)]], [[सही]], स्मॉलटॉक, [[टीसीएल]], [[विजुअल प्रोलॉग]] और अधिकांश .नेट भाषाएँ होती है|
-सामान्य वाक्य-विन्यास अंतरों को छोड़कर, उपयोग में केवल कुछ अपवाद हैंडलिंग शैलियाँ हैं। सबसे लोकप्रिय शैली में, एक विशेष कथन द्वारा एक अपवाद प्रारंभिक किया जाता है (<code>throw</code> या <code>raise</code>) एक अपवाद वस्तु के साथ (उदाहरण के लिए जावा या ऑब्जेक्ट पास्कल के साथ) या एक विशेष विस्तार योग्य एन्युमरेटेड प्रकार का मान (जैसे एडा या एसएमएल के साथ)। अपवाद संचालकों के लिए दायरा एक मार्कर क्लॉज से प्रारंभिक होता है (<code>try</code> या भाषा का ब्लॉक स्टार्टर जैसे <code>begin</code>) और पहले हैंडलर क्लॉज की प्रारंभमें समाप्त होता है (<code>catch</code>, <code>except</code>, <code>rescue</code>). कई हैंडलर क्लॉज अनुसरण कर सकते हैं, और प्रत्येक निर्दिष्ट कर सकता है कि यह किस अपवाद प्रकार को संभालता है और अपवाद वस्तु के लिए किस नाम का उपयोग करता है। सामान्य भिन्नता के रूप में, कुछ भाषाएँ एकल हैंडलर खंड का उपयोग करती हैं, जो आंतरिक रूप से अपवाद के वर्ग से संबंधित है।
+सामान्य वाक्य-विन्यास अंतरों को छोड़कर, उपयोग में केवल कुछ अपवाद प्रबंधन शैलियाँ हैं। सबसे लोकप्रिय शैली में, एक विशेष कथन द्वारा एक अपवाद प्रारंभिक किया जाता है (<code>throw</code> या <code>raise</code>) एक अपवाद वस्तु के साथ (उदाहरण के लिए जावा या ऑब्जेक्ट पास्कल के साथ) या एक विशेष विस्तार योग्य एन्युमरेटेड प्रकार का मान (जैसे एडा या एसएमएल के साथ)। अपवाद संचालकों के लिए दायरा एक मार्कर क्लॉज से प्रारंभिक होता है (<code>try</code> या भाषा का ब्लॉक स्टार्टर जैसे <code>begin</code>) और पहले प्रबंधक क्लॉज की प्रारंभमें समाप्त होता है (<code>catch</code>, <code>except</code>, <code>rescue</code>). कई प्रबंधक क्लॉज अनुसरण कर सकते हैं, और प्रत्येक निर्दिष्ट कर सकता है कि यह किस अपवाद प्रकार को संभालता है और अपवाद वस्तु के लिए किस नाम का उपयोग करता है। सामान्य भिन्नता के रूप में, कुछ भाषाएँ एकल प्रबंधक खंड का उपयोग करती हैं, जो आंतरिक रूप से अपवाद के वर्ग से संबंधित है।
-इसके अतिरिक्त सामान्य एक संबंधित खंड है (<code>finally</code> या <code>ensure</code>) जिसे निष्पादित किया जाता है चाहे कोई अपवाद हुआ हो या नहीं, सामान्यतः अपवाद-हैंडलिंग ब्लॉक के शरीर के अंदर प्राप्त संसाधनों को जारी करने के लिए। विशेष रूप से, सी ++ यह निर्माण प्रदान नहीं करता है, इसके अतिरिक्त [[संसाधन अधिग्रहण प्रारंभ है]] (RAII) विधि की पक्षसमर्थन करता है जो डिस्ट्रक्टर (कंप्यूटर प्रोग्रामिंग) का उपयोग करके संसाधनों को मुक्त करता है।<ref>{{cite web |last1=Stroustrup |first1=Bjarne |title=C++ Style and Technique FAQ |url=https://www.stroustrup.com/bs_faq2.html#finally |website=www.stroustrup.com |access-date=12 January 2022}}</ref> वेस्टली वीमर और [[जॉर्ज नेकुला]] द्वारा 2008 के एक पेपर के अनुसार, वाक्य रचना <code>try</code>...<code>finally</code> जावा में ब्लॉक सॉफ्टवेयर दोषों के लिए एक योगदान कारक है। जब एक विधि को 3-5 संसाधनों के अधिग्रहण और रिलीज को संभालने की आवश्यकता होती है, तो प्रोग्रामर स्पष्ट रूप से पठनीयता संबंधी चिंताओं के कारण पर्याप्त ब्लॉकों को नेस्ट करने के लिए तैयार नहीं होते हैं, तब भी जब यह एक सही समाधान होगा। सिंगल का उपयोग करना संभव है <code>try</code>...<code>finally</code> कई संसाधनों के साथ काम करते समय भी ब्लॉक करें, किन्तु इसके लिए [[प्रहरी मूल्य]]ों के सही उपयोग की आवश्यकता होती है, जो इस प्रकार की समस्या के लिए बग का एक अन्य सामान्य स्रोत है।<ref name="toplas2008"/>{{rp|8:6–8:7}}
+इसके अतिरिक्त सामान्य एक संबंधित खंड है (<code>finally</code> या <code>ensure</code>) जिसे निष्पादित किया जाता है चाहे कोई अपवाद हुआ हो या नहीं, सामान्यतः अपवाद-प्रबंधन ब्लॉक के शरीर के अंदर प्राप्त संसाधनों को जारी करने के लिए। विशेष रूप से, C++ यह निर्माण प्रदान नहीं करता है, इसके अतिरिक्त [[संसाधन अधिग्रहण प्रारंभ है]] (RAII) विधि की पक्षसमर्थन करता है जो डिस्ट्रक्टर (कंप्यूटर प्रोग्रामिंग) का उपयोग करके संसाधनों को मुक्त करता है।<ref>{{cite web |last1=Stroustrup |first1=Bjarne |title=C++ Style and Technique FAQ |url=https://www.stroustrup.com/bs_faq2.html#finally |website=www.stroustrup.com |access-date=12 January 2022}}</ref> वेस्टली वीमर और [[जॉर्ज नेकुला]] द्वारा 2008 के एक पेपर के अनुसार, वाक्य रचना <code>try</code>...<code>finally</code> जावा में ब्लॉक सॉफ्टवेयर दोषों के लिए एक योगदान कारक है। जब एक विधि को 3-5 संसाधनों के अधिग्रहण और रिलीज को संभालने की आवश्यकता होती है, तो प्रोग्रामर स्पष्ट रूप से पठनीयता संबंधी चिंताओं के कारण पर्याप्त ब्लॉकों को नेस्ट करने के लिए तैयार नहीं होते हैं, तब भी जब यह एक सही समाधान होगा। सिंगल का उपयोग करना संभव है <code>try</code>...<code>finally</code> कई संसाधनों के साथ काम करते समय भी ब्लॉक करें, किन्तु इसके लिए [[प्रहरी मूल्य|प्रहरी]] मूल्यों के सही उपयोग की आवश्यकता होती है, जो इस प्रकार की समस्या के लिए बग का एक अन्य सामान्य स्रोत है।<ref name="toplas2008"/>{{rp|8:6–8:7}}
-पायथन और रूबी भी एक खंड की अनुमति देते हैं (<code>else</code>) जिसका उपयोग हैंडलर के सीमा के अंत तक पहुंचने से पहले कोई अपवाद नहीं होने पर किया जाता है।
+पायथन और रूबी भी एक खंड की अनुमति देते हैं (<code>else</code>) जिसका उपयोग प्रबंधक के सीमा के अंत तक पहुंचने से पहले कोई अपवाद नहीं होने पर किया जाता है।
-अपने पूरे में, अपवाद हैंडलिंग कोड इस तरह दिख सकता है (जावा (प्रोग्रामिंग भाषा) में - [[स्यूडोकोड]] की तरह):<syntaxhighlight>
+अपने पूरे में, अपवाद प्रबंधन कोड इस तरह दिख सकता है (जावा (प्रोग्रामिंग भाषा) में - [[स्यूडोकोड]] की तरह):<syntaxhighlight>
 try {
      line = console.readLine();
@@ Line 109: / Line 108: @@
 </syntaxhighlight>
-C में ट्राई-कैच अपवाद हैंडलिंग नहीं है, किन्तु त्रुटि जाँच के लिए रिटर्न कोड का उपयोग करता है। समुच्चयजम्प.एच |<code>setjmp</code> और <code>longjmp</code>मैक्रोज़ के माध्यम से ट्राइ-कैच हैंडलिंग को प्रयुक्त करने के लिए मानक लाइब्रेरी फ़ंक्शंस का उपयोग किया जा सकता है।<ref>{{cite journal |last1=Roberts |first1=Eric S. |title=Implementing Exceptions in C |date=21 March 1989 |url=http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/tech_reports/SRC-RR-40.pdf |access-date=4 January 2022 |publisher=[[DEC Systems Research Center]] |id=SRC-RR-40}}</ref>
+C में ट्राई-कैच अपवाद प्रबंधन नहीं है, किन्तु त्रुटि जाँच के लिए वापसी कोड का उपयोग करता है। समुच्चय जम्प.एच |<code>setjmp</code> और <code>longjmp</code>मैक्रोज़ के माध्यम से ट्राइ-कैच प्रबंधन को प्रयुक्त करने के लिए मानक पुस्तकालय फलन का उपयोग किया जा सकता है।<ref>{{cite journal |last1=Roberts |first1=Eric S. |title=Implementing Exceptions in C |date=21 March 1989 |url=http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/tech_reports/SRC-RR-40.pdf |access-date=4 January 2022 |publisher=[[DEC Systems Research Center]] |id=SRC-RR-40}}</ref>
 [[पर्ल]] 5 उपयोग करता है <code>die</code> के लिए <code>throw</code> और <code>eval {} if ($@) {}</code> ट्राई-कैच के लिए। इसमें सीपीएएन मॉड्यूल हैं जो ट्राइ-कैच सेमेन्टिक्स प्रदान करते हैं।<ref>{{cite book |last1=Christiansen |first1=Tom |last2=Torkington |first2=Nathan |title=Perl cookbook |date=2003 |publisher=O'Reilly |location=Beijing |isbn=0-596-00313-7 |edition=2nd |url=https://docstore.mik.ua/orelly/perl4/cook/ch10_13.htm |chapter=10.12. Handling Exceptions}}</ref>
 === समाप्ति और बहाली शब्दार्थ ===
-जब एक अपवाद फेंका जाता है, तो प्रोग्राम फ़ंक्शन कॉल के [[कॉल स्टैक]] के माध्यम से वापस खोजता है जब तक कि एक अपवाद हैंडलर नहीं मिल जाता। जैसे ही यह खोज आगे बढ़ती है, कुछ भाषाओं में स्टैक को खोलने की आवश्यकता होती है। अर्थात यदि फलन   {{mono|f}}, एक हैंडलर युक्त  {{mono|H}} अपवाद के लिए {{mono|E}}, फ़ंक्शन कॉल करता है {{mono|g}}, जो बदले में फ़ंक्शन को कॉल करता है {{mono|h}}, और एक अपवाद {{mono|E}} में होता है {{mono|h}}, फिर कार्य करता है {{mono|h}} और {{mono|g}} समाप्त किया जा सकता है, और {{mono|H}} में {{mono|f}} सम्हाल लेंगे {{mono|E}}. इसे समाप्ति शब्दार्थ कहा जाता है।
+जब एक अपवाद प्रक्षेपण जाता है, तो प्रोग्राम फलन कॉल के [[कॉल स्टैक]] के माध्यम से वापस खोजता है जब तक कि एक अपवाद प्रबंधक नहीं मिल जाता। जैसे ही यह खोज आगे बढ़ती है, कुछ भाषाओं में स्टैक को खोलने की आवश्यकता होती है। अर्थात यदि फलन {{mono|f}}, एक प्रबंधक युक्त {{mono|H}} अपवाद के लिए {{mono|E}}, फलन पुकारता है {{mono|g}}, जो बदले में फलन को पुकारता है {{mono|h}}, और एक अपवाद {{mono|E}} में होता है {{mono|h}}, फिर कार्य करता है {{mono|h}} और {{mono|g}} समाप्त किया जा सकता है, और {{mono|H}} में {{mono|f}} सम्हाल लेंगे {{mono|E}}. इसे समाप्ति शब्दार्थ कहा जाता है।
-वैकल्पिक रूप से, अपवाद हैंडलिंग तंत्र प्रवेश पर ढेर को खोलना नहीं हो सकता है<ref group=note>In, e.g., PL/I, a normal exit from an exception handler unwinds the stack.</ref> अपवाद हैंडलर को, अपवाद हैंडलर को संगणना फिर से प्रारंभिक करने, फिर से प्रारंभिक करने या खोलने का विकल्प देता है। यह प्रोग्राम को ठीक उसी स्थान पर गणना जारी रखने की अनुमति देता है जहां त्रुटि हुई थी (उदाहरण के लिए जब पहले से गायब फ़ाइल उपलब्ध हो गई हो) या अपवाद हैंडलिंग तंत्र के शीर्ष पर सूचनाएं, लॉगिंग, क्वेरीज़ और द्रव चर प्रयुक्त करने के लिए (जैसा कि किया गया है) स्मॉलटॉक में)। गणना को फिर से प्रारंभिक करने की अनुमति देना जहां इसे छोड़ा गया था, को फिर से प्रारंभिक करना शब्दार्थ कहा जाता है।
+वैकल्पिक रूप से, अपवाद प्रबंधन तंत्र अपवाद प्रबंधक के लिए प्रविष्टि [नोट 1] पर स्टैक को खोलना नहीं हो सकता है<ref group="note">In, e.g., PL/I, a normal exit from an exception handler unwinds the stack.</ref> अपवाद प्रबंधक को,संगणना फिर से प्रारंभिक करने, या खोलने का विकल्प देता है। यह प्रोग्राम को ठीक उसी स्थान पर गणना जारी रखने की अनुमति देता है जहां त्रुटि हुई थी (उदाहरण के लिए जब पहले से गायब फ़ाइल उपलब्ध हो गई हो) या अपवाद प्रबंधन तंत्र के शीर्ष पर सूचनाएं, लॉगिंग, प्रश्न और द्रव चर प्रयुक्त करने के लिए (जैसा कि किया गया है) लघु वार्ता में)। गणना को फिर से प्रारंभिक करने की अनुमति देना जहां इसे छोड़ा गया था, को फिर से प्रारंभिक करना शब्दार्थ कहा जाता है।
-किसी भी निर्णय के पक्ष में सैद्धांतिक और डिजाइन तर्क हैं। 1989-1991 में C++ मानकीकरण चर्चाओं के परिणामस्वरूप C++ में टर्मिनेशन सिमेंटिक्स का उपयोग करने का एक निश्चित निर्णय हुआ।{{sfn|Stroustrup|1994|loc=16.6 Exception Handling: Resumption vs. Termination, pp. 390–393}} [[बज़्ने स्ट्रॉस्ट्रुप]] एक महत्वपूर्ण डेटा बिंदु के रूप में जेम्स जी. मिशेल की एक प्रस्तुति का हवाला देते हैं:
-{{blockquote|Jim had used exception handling in half a dozen languages over a period of 20 years and was an early proponent of resumption semantics as one of the main designers and implementers of Xerox's [[Mesa/Cedar|Cedar/Mesa]] system. His message was
-:“termination is preferred over resumption; this is not a matter of opinion but a matter of years of experience. Resumption is seductive, but not valid.”
-He backed this statement with experience from several operating systems. The key example was Cedar/Mesa: It was written by people who liked and used resumption, but after ten years of use, there was only one use of resumption left in the half million line system – and that was a context inquiry. Because resumption wasn't actually necessary for such a context inquiry, they removed it and found a significant speed increase in that part of the system. In each and every case where resumption had been used it had – over the ten years – become a problem and a more appropriate design had replaced it. Basically, every use of resumption had represented a failure to keep separate levels of abstraction disjoint.{{sfn|Stroustrup|1994|p=392}}}}
-बहाली के साथ अपवाद-हैंडलिंग भाषाओं में  या कंडीशन प्रणाली के साथ कॉमन लिस्प, PL/I, डायलन, R_(प्रोग्रामिंग_लैंग्वेज) सम्मिलित हैं।<ref>{{Cite web |title=R: Condition Handling and Recovery |url=https://search.r-project.org/R/refmans/base/html/conditions.html |access-date=2022-12-05 |website=search.r-project.org}}</ref> और स्मॉलटॉक। चूंकि, अधिकांश नई प्रोग्रामिंग भाषाएँ C ++ का अनुसरण करती हैं और समाप्ति शब्दार्थ का उपयोग करती हैं।
+किसी भी निर्णय के पक्ष में सैद्धांतिक और रचना तर्क हैं। 1989-1991 में C++ मानकीकरण चर्चाओं के परिणामस्वरूप C++ में समापन अर्थ विज्ञान का उपयोग करने का एक निश्चित निर्णय हुआ।{{sfn|Stroustrup|1994|loc=16.6 Exception Handling: Resumption vs. Termination, pp. 390–393}} [[बज़्ने स्ट्रॉस्ट्रुप]] एक महत्वपूर्ण डेटा बिंदु के रूप में जेम्स जी. मिशेल की एक प्रस्तुति का हवाला देते हैं:
+{{blockquote|जिम ने 20 वर्षों की अवधि में आधा दर्जन भाषाओं में अपवाद प्रबंधन का उपयोग किया था और जेरोक्स के [[मेसा/सीडर|सीडर/मेसा]] प्रणाली के मुख्य डिजाइनरों और कार्यान्वयनकर्ताओं में से एक के रूप में बहाली शब्दार्थ के प्रारंभिक प्रस्तावक थे। उनका संदेश था
+:“समाप्ति को फिर से शुरू करने से अधिक पसंद किया जाता है; यह कोई राय की बात नहीं है बल्कि वर्षों के अनुभव की बात है। बहाली मोहक है, लेकिन मान्य नहीं है।
+उन्होंने कई ऑपरेटिंग प्रणाली के अनुभव के साथ इस कथन का समर्थन किया। मुख्य उदाहरण सीडर/मेसा था: यह उन लोगों द्वारा लिखा गया था जो पसंद करते थे और फिर से प्रारंभ करना पसंद करते थे, लेकिन दस साल के उपयोग के बाद, आधे मिलियन लाइन प्रणाली में केवल एक ही बहाली का उपयोग बचा था - और वह एक संदर्भ पूछताछ थी। क्योंकि इस तरह की एक संदर्भ जांच के लिए वास्तव में बहाली जरूरी नहीं थी, उन्होंने इसे हटा दिया और प्रणाली के उस हिस्से में एक महत्वपूर्ण गति वृद्धि पाई। प्रत्येक मामले में जहां बहाली का उपयोग किया गया था - दस वर्षों में - एक समस्या बन गई थी और एक अधिक उपयुक्त डिजाइन ने इसे बदल दिया था। मूल रूप से, पुन: आरंभ के प्रत्येक प्रयोग ने अमूर्तता के अलग-अलग स्तरों को अलग रखने में विफलता का प्रतिनिधित्व किया था। {{sfn|Stroustrup|1994|p=392}}}}
-=== अपवाद हैंडलिंग कार्यान्वयन ===
+बहाली के साथ अपवाद-प्रबंधन भाषाओं में या स्थिति प्रणाली के साथ कॉमन लिस्प, पीएल/आई, डायलन, R_(प्रोग्रामिंग_भाषा) सम्मिलित हैं।<ref>{{Cite web |title=R: Condition Handling and Recovery |url=https://search.r-project.org/R/refmans/base/html/conditions.html |access-date=2022-12-05 |website=search.r-project.org}}</ref> और लघु वार्ता। चूंकि, अधिकांश नई प्रोग्रामिंग भाषाएँ C ++ का अनुसरण करती हैं और समाप्ति शब्दार्थ का उपयोग करती हैं।
-प्रोग्रामिंग भाषाओं में अपवाद हैंडलिंग के कार्यान्वयन में सामान्यतः एक कोड जनरेटर और एक कंपाइलर के साथ [[रनटाइम सिस्टम|रनटाइम प्रणाली]] दोनों से उचित मात्रा में समर्थन सम्मिलित होता है। (यह सी ++ में अपवाद हैंडलिंग का जोड़ था जिसने मूल सी ++ कंपाइलर, [[सामने]] के उपयोगी जीवनकाल को समाप्त कर दिया।<ref>[[Scott Meyers]], [http://www.artima.com/cppsource/top_cpp_software.html The Most Important C++ Software...Ever] {{webarchive|url=https://web.archive.org/web/20110428221802/http://www.artima.com/cppsource/top_cpp_software.html |date=2011-04-28 }}, 2006</ref>) दो योजनाएँ सबसे आम हैं। पहला,{{visible anchor|dynamic registration}}, कोड उत्पन्न करता है जो अपवाद प्रबंधन के संदर्भ में प्रोग्राम स्थिति के बारे में संरचनाओं को लगातार अद्यतन करता है।<ref>D. Cameron, P. Faust, D. Lenkov, M. Mehta, "A portable implementation of C++ exception handling", ''Proceedings of the C++ Conference'' (August 1992) [[USENIX]].</ref> सामान्यतः, यह कॉल स्टैक में एक नया तत्व जोड़ता है जो जानता है कि उस फ्रेम से जुड़े फ़ंक्शन या विधि के लिए कौन से हैंडलर उपलब्ध हैं; यदि कोई अपवाद फेंका जाता है, तो लेआउट में एक सूचक रनटाइम को उचित हैंडलर कोड पर निर्देशित करता है। यह दृष्टिकोण अंतरिक्ष के मामले में कॉम्पैक्ट है, किन्तु फ्रेम प्रविष्टि और निकास पर निष्पादन ओवरहेड जोड़ता है। यह सामान्यतः कई एडीए कार्यान्वयनों में उपयोग किया जाता था, उदाहरण के लिए, जहां कई अन्य भाषा सुविधाओं के लिए जटिल पीढ़ी और रनटाइम समर्थन की पहले से ही आवश्यकता थी। Microsoft का 32-बिट [[संरचित अपवाद हैंडलिंग]] (SEH) एक अलग अपवाद स्टैक के साथ इस दृष्टिकोण का उपयोग करता है।<ref>{{cite web|url=http://stoned-vienna.com/html/index.php?page=windows-exception-handling|author=Peter Kleissner|title=Windows Exception Handling - Peter Kleissner|date=February 14, 2009|access-date=2009-11-21 |archive-url=https://web.archive.org/web/20131014204335/http://stoned-vienna.com/html/index.php?page=windows-exception-handling |archive-date=October 14, 2013 |url-status=dead}}, ''Compiler based Structured Exception Handling'' section</ref> डायनेमिक पंजीकरण, परिभाषित करने के लिए अधिक सरल होने के कारण, शुद्धता के प्रमाण के लिए उत्तरदायी है।<ref>Graham Hutton, Joel Wright, "[http://www.cs.nott.ac.uk/~gmh/exceptions.pdf Compiling Exceptions Correctly] {{webarchive|url=https://web.archive.org/web/20140911173720/http://www.cs.nott.ac.uk/~gmh/exceptions.pdf |date=2014-09-11 }}". ''Proceedings of the 7th International Conference on Mathematics of Program Construction'', 2004.</ref>
-दूसरी योजना, और कई उत्पादन-गुणवत्ता वाले C++ कंपाइलरों और 64-बिट Microsoft संरचित अपवाद हैंडलिंग में प्रयुक्त की गई, एक है {{visible anchor|table-driven approach|text=''table-driven'' approach}}. यह [[संकलन समय]] और [[लिंक समय]] पर स्थिर तालिकाएँ बनाता है जो अपवाद हैंडलिंग के संबंध में [[कार्यक्रम गणक]] की प्रोग्राम स्थिति से संबंधित होती हैं।<ref>{{cite journal | title=Exception handling – Supporting the runtime mechanism | last=Lajoie | first= Josée | journal=C++ Report | volume=6 | issue=3 | date=March–April 1994}}</ref> फिर, यदि कोई अपवाद फेंका जाता है, तो रनटाइम प्रणाली तालिकाओं में वर्तमान निर्देश स्थान को देखता है और यह निर्धारित करता है कि कौन से हैंडलर चल रहे हैं और क्या करने की आवश्यकता है। यह दृष्टिकोण उस मामले के लिए कार्यकारी ओवरहेड को कम करता है जहां अपवाद नहीं फेंका जाता है। यह कुछ स्थान की कीमत पर होता है, किन्तु इस स्थान को केवल-पढ़ने के लिए, विशेष-उद्देश्य वाले डेटा अनुभागों में आवंटित किया जा सकता है जो वास्तव में एक अपवाद फेंके जाने तक लोड या स्थानांतरित नहीं होते हैं।<ref name="cppeh">{{cite journal | title=Optimizing away C++ exception handling | last=Schilling | first=Jonathan L. | journal=[[SIGPLAN Notices]] | volume=33 | issue=8 | date=August 1998 | pages=40–47 | doi=10.1145/286385.286390| s2cid=1522664 }}</ref> एक अपवाद को संभालने के लिए कोड का स्थान (स्मृति में) मेमोरी के उस क्षेत्र के अंदर (या उसके पास भी) स्थित होना चाहिए जहां बाकी फ़ंक्शन का कोड संग्रहीत है। तो यदि एक अपवाद फेंक दिया जाता है तो एक प्रदर्शन हिट - मोटे तौर पर एक फ़ंक्शन कॉल के बराबर<ref name="MiscrosoftDocsExceptions">{{cite web|title=Modern C++ best practices for exceptions and error handling|work=Microsoft|date=8 March 2021|access-date=21 March 2022|url=https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp}}</ref> - हो सकता है यदि आवश्यक अपवाद हैंडलिंग कोड को लोड/कैश करने की आवश्यकता हो। चूंकि, इस योजना की न्यूनतम प्रदर्शन निवेश है यदि कोई अपवाद नहीं फेंका जाता है। चूँकि C++ में अपवादों को असाधारण (अर्थात असामान्य/दुर्लभ) घटनाएँ माना जाता है, वाक्यांश शून्य-निवेश अपवाद<ref group="note">There is "zero [processing] cost" only if no exception is throw (although there will be a memory cost since memory is needed for the lookup table). There is a (potentially significant) cost if an exception is thrown (that is, if <code>throw</code> is executed). Implementing exception handling may also limit the possible [[Optimizing compiler|compiler optimizations]] that may be performed.</ref> कभी-कभी सी ++ में अपवाद हैंडलिंग का वर्णन करने के लिए प्रयोग किया जाता है। [[रनटाइम प्रकार की पहचान]] (RTTI) की तरह, अपवाद C++ के [https://en.cppreference.com/w/cpp/language/Zero-overhead_principle शून्य-ओवरहेड सिद्धांत] का पालन नहीं कर सकते हैं क्योंकि रन-टाइम पर अपवाद हैंडलिंग को प्रयुक्त करने के लिए एक गैर की आवश्यकता होती है। लुकअप टेबल के लिए शून्य मात्रा में मेमोरी।<ref name="StroustrupExceptions2019">{{cite web|last=Stroustrup|first=Bjarne|author-link=Bjarne Stroustrup|title=C++ exceptions and alternatives|date=18 November 2019|access-date=23 March 2022|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf}}</ref> इस कारण से, अपवाद प्रबंधन (और आरटीटीआई) को कई सी ++ कंपाइलर्स में अक्षम किया जा सकता है, जो कि बहुत सीमित स्मृति वाले प्रणाली के लिए उपयोगी हो सकता है<ref name="StroustrupExceptions2019" />(जैसे [[अंतः स्थापित प्रणाली]])। थ्रेड सुरक्षा प्राप्त करने के मामले में यह दूसरा दृष्टिकोण भी उत्तम  है.
+=== अपवाद प्रबंधन कार्यान्वयन ===
+प्रोग्रामिंग भाषाओं में अपवाद प्रबंधन के कार्यान्वयन में सामान्यतः एक कोड जनरेटर और एक कंपाइलर के साथ [[रनटाइम सिस्टम|रनटाइम प्रणाली]] दोनों से उचित मात्रा में समर्थन सम्मिलित होता है। (यह C++ में अपवाद प्रबंधन का जोड़ था जिसने मूल C++ कंपाइलर, [[सामने]] के उपयोगी जीवनकाल को समाप्त कर दिया।<ref>[[Scott Meyers]], [http://www.artima.com/cppsource/top_cpp_software.html The Most Important C++ Software...Ever] {{webarchive|url=https://web.archive.org/web/20110428221802/http://www.artima.com/cppsource/top_cpp_software.html |date=2011-04-28 }}, 2006</ref>) दो योजनाएँ सबसे आम हैं। पहला,{{visible anchor|गतिशील पंजीकरण}}, कोड उत्पन्न करता है जो अपवाद प्रबंधन के संदर्भ में प्रोग्राम स्थिति के बारे में संरचनाओं को लगातार अद्यतन करता है।<ref>D. Cameron, P. Faust, D. Lenkov, M. Mehta, "A portable implementation of C++ exception handling", ''Proceedings of the C++ Conference'' (August 1992) [[USENIX]].</ref> सामान्यतः, यह कॉल स्टैक में एक नया तत्व जोड़ता है जो जानता है कि उस फ्रेम से जुड़े कार्य  या विधि के लिए कौन से प्रबंधक उपलब्ध हैं; यदि कोई अपवाद जाता है, तो विन्यास में एक सूचक कार्यविधि को उचित प्रबंधक कोड पर निर्देशित करता है। यह दृष्टिकोण अंतरिक्ष के स्थितियों में कॉम्पैक्ट है, किन्तु फ्रेम प्रविष्टि और निकास पर निष्पादन ओवरहेड जोड़ता है। यह सामान्यतः कई एडीए कार्यान्वयनों में उपयोग किया जाता था, उदाहरण के लिए, जहां कई अन्य भाषा सुविधाओं के लिए जटिल पीढ़ी और कार्यविधि समर्थन की पहले से ही आवश्यकता थी। माइक्रोसॉफ्ट का 32-बिट [[संरचित अपवाद हैंडलिंग|संरचित अपवाद प्रबंधन]] (एसईएच) एक अलग अपवाद स्टैक के साथ इस दृष्टिकोण का उपयोग करता है।<ref>{{cite web|url=http://stoned-vienna.com/html/index.php?page=windows-exception-handling|author=Peter Kleissner|title=Windows Exception Handling - Peter Kleissner|date=February 14, 2009|access-date=2009-11-21 |archive-url=https://web.archive.org/web/20131014204335/http://stoned-vienna.com/html/index.php?page=windows-exception-handling |archive-date=October 14, 2013 |url-status=dead}}, ''Compiler based Structured Exception Handling'' section</ref> डायनेमिक पंजीकरण, परिभाषित करने के लिए अधिक सरल होने के कारण, शुद्धता के प्रमाण के लिए उत्तरदायी होता है।<ref>Graham Hutton, Joel Wright, "[http://www.cs.nott.ac.uk/~gmh/exceptions.pdf Compiling Exceptions Correctly] {{webarchive|url=https://web.archive.org/web/20140911173720/http://www.cs.nott.ac.uk/~gmh/exceptions.pdf |date=2014-09-11 }}". ''Proceedings of the 7th International Conference on Mathematics of Program Construction'', 2004.</ref>
+दूसरी योजना, और कई उत्पादन-गुणवत्ता वाले C++ कंपाइलरों और 64-बिट माइक्रोसॉफ्ट संरचित अपवाद प्रबंधन में प्रयुक्त की गई, एक {{visible anchor|टेबल-संचालित दृष्टिकोण|text=टेबल-संचालित दृष्टिकोण}} है| यह [[संकलन समय]] और [[लिंक समय]] पर स्थिर तालिकाएँ बनाता है जो अपवाद प्रबंधन के संबंध में [[कार्यक्रम गणक]] की प्रोग्राम स्थिति से संबंधित होती हैं।<ref>{{cite journal | title=Exception handling – Supporting the runtime mechanism | last=Lajoie | first= Josée | journal=C++ Report | volume=6 | issue=3 | date=March–April 1994}}</ref> फिर, यदि कोई अपवाद प्रछेपड है, तो कार्यविधि प्रणाली तालिकाओं में वर्तमान निर्देश स्थान को देखता है और यह निर्धारित करता है कि कौन से प्रबंधक चल रहे हैं और क्या करने की आवश्यकता होती है। यह दृष्टिकोण उस स्थितियों के लिए कार्यकारी ओवरहेड को कम करता है जहां अपवाद नहीं प्रछेपड है। यह कुछ स्थान की कीमत पर होता है, किन्तु इस स्थान को केवल-पढ़ने के लिए, विशेष-उद्देश्य वाले डेटा अनुभागों में आवंटित किया जा सकता है जो वास्तव में एक अपवाद फेंके जाने तक लोड या स्थानांतरित नहीं होते हैं।<ref name="cppeh">{{cite journal | title=Optimizing away C++ exception handling | last=Schilling | first=Jonathan L. | journal=[[SIGPLAN Notices]] | volume=33 | issue=8 | date=August 1998 | pages=40–47 | doi=10.1145/286385.286390| s2cid=1522664 }}</ref> एक अपवाद को संभालने के लिए कोड का स्थान (स्मृति में) मेमोरी के उस क्षेत्र के अंदर (या उसके पास भी) स्थित होना चाहिए| जहां बाकी फलन का कोड संग्रहीत होता है। तो यदि एक अपवाद फेंक दिया जाता है तो एक प्रदर्शन हिट - मोटे तौर पर एक फलन कॉल के बराबर<ref name="MiscrosoftDocsExceptions">{{cite web|title=Modern C++ best practices for exceptions and error handling|work=Microsoft|date=8 March 2021|access-date=21 March 2022|url=https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp}}</ref> - हो सकता है यदि आवश्यक अपवाद प्रबंधन कोड को लोड/कैश करने की आवश्यकता हो। चूंकि, इस योजना की न्यूनतम प्रदर्शन निवेश है यदि कोई अपवाद नहीं फेंका जाता है। चूँकि C++ में अपवादों को असाधारण (अर्थात असामान्य/दुर्लभ) घटनाएँ माना जाता है, वाक्यांश शून्य-निवेश अपवाद<ref group="note">There is "zero [processing] cost" only if no exception is throw (although there will be a memory cost since memory is needed for the lookup table). There is a (potentially significant) cost if an exception is thrown (that is, if <code>throw</code> is executed). Implementing exception handling may also limit the possible [[Optimizing compiler|compiler optimizations]] that may be performed.</ref> कभी-कभी c ++ में अपवाद प्रबंधन का वर्णन करने के लिए प्रयोग किया जाता है। [[रनटाइम प्रकार की पहचान]] (आरटीटीआई) की तरह, अपवाद C++ के [https://en.cppreference.com/w/cpp/language/Zero-overhead_principle शून्य-ओवरहेड सिद्धांत] का पालन नहीं कर सकते हैं क्योंकि रन-टाइम पर अपवाद प्रबंधन को प्रयुक्त करने के लिए एक गैर की आवश्यकता होती है। लुकअप सारिणी के लिए शून्य मात्रा में मेमोरी।<ref name="StroustrupExceptions2019">{{cite web|last=Stroustrup|first=Bjarne|author-link=Bjarne Stroustrup|title=C++ exceptions and alternatives|date=18 November 2019|access-date=23 March 2022|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf}}</ref> इस कारण से, अपवाद प्रबंधन (और आरटीटीआई) को कई C++ कंपाइलर्स में अक्षम किया जा सकता है, जो कि बहुत सीमित स्मृति वाले प्रणाली के लिए उपयोगी हो सकता है<ref name="StroustrupExceptions2019" />(जैसे [[अंतः स्थापित प्रणाली]])। कड़ी सुरक्षा प्राप्त करने के स्थितियों में यह दूसरा दृष्टिकोण भी उत्तम है.
 अन्य निश्चित और कार्यान्वयन योजनाओं को भी प्रस्तावित किया गया है। [[मेटाप्रोग्रामिंग]] का समर्थन करने वाली भाषाओं के लिए, दृष्टिकोण जिसमें कोई ओवरहेड सम्मिलित नहीं है ([[प्रतिबिंब (कंप्यूटर विज्ञान)]] के लिए पहले से उपस्थित समर्थन से परे) को उन्नत किया गया है।<ref>M. Hof, H. Mössenböck, P. Pirkelbauer, "[http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html Zero-Overhead Exception Handling Using Metaprogramming] {{webarchive|url=https://web.archive.org/web/20160303180327/http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html |date=2016-03-03 }}", ''Proceedings SOFSEM'97'', November 1997, ''Lecture Notes in Computer Science 1338'', pp. 423-431.</ref>
@@ Line 134: / Line 137: @@
-=== [[अनुबंध द्वारा डिजाइन]] के आधार पर अपवाद हैंडलिंग ===
+=== [[अनुबंध द्वारा डिजाइन|अनुबंध द्वारा रचना]] के आधार पर अपवाद प्रबंधन ===
-अपवादों का एक अलग दृष्टिकोण अनुबंध द्वारा डिजाइन के सिद्धांतों पर आधारित है और विशेष रूप से एफिल (प्रोग्रामिंग भाषा) द्वारा समर्थित है। विचार यह है कि सामान्य और असामान्य व्यवहार क्या है, इसे स्पष्ट रूप से परिभाषित करके अपवाद से निपटने के लिए अधिक कठोर आधार प्रदान किया जाए। विशेष रूप से, दृष्टिकोण दो अवधारणाओं पर आधारित है:
+अपवादों का एक अलग दृष्टिकोण अनुबंध द्वारा रचना के सिद्धांतों पर आधारित है और विशेष रूप से एफिल (प्रोग्रामिंग भाषा) द्वारा समर्थित है। विचार यह है कि सामान्य और असामान्य व्यवहार क्या है, इसे स्पष्ट रूप से परिभाषित करके अपवाद से निपटने के लिए अधिक कठोर आधार प्रदान किया जाते है| विशेष रूप से, दृष्टिकोण दो अवधारणाओं पर आधारित है|:
-* असफलता: अपने अनुबंध को पूरा करने के लिए एक ऑपरेशन की अक्षमता। उदाहरण के लिए, एक जोड़ एक अंकगणितीय अतिप्रवाह उत्पन्न कर सकता है (यह गणितीय योग के लिए एक अच्छा सन्निकटन कंप्यूटिंग के अपने अनुबंध को पूरा नहीं करता है); या कोई रूटीन अपनी पोस्टकंडिशन को पूरा करने में विफल हो सकता है।
+* असफलता: अपने अनुबंध को पूरा करने के लिए एक ऑपरेशन की अक्षमता। उदाहरण के लिए, एक जोड़ एक अंकगणितीय अतिप्रवाह उत्पन्न कर सकता है (यह गणितीय योग के लिए एक अच्छा सन्निकटन कंप्यूटिंग के अपने अनुबंध को पूरा नहीं करता है); या कोई प्रक्रिया अपनी पद की स्थिति को पूरा करने में विफल हो सकता है।
-* अपवाद: एक रूटीन के निष्पादन के समय होने वाली एक असामान्य घटना (वह रूटीन अपवाद का ''प्राप्तकर्ता'' है) इसके निष्पादन के दौरान। इस तरह की असामान्य घटना नियमित रूप से कहे जाने वाले ऑपरेशन की 'विफलता' का परिणाम होती है।
+* अपवाद: एक प्रक्रिया के निष्पादन के समय होने वाली एक असामान्य घटना (वह प्रक्रिया अपवाद का ''प्राप्तकर्ता'' है) इसके निष्पादन के दौरान। इस तरह की असामान्य घटना नियमित रूप से कहे जाने वाले ऑपरेशन की 'विफलता' का परिणाम होती है।
-[[वस्तु-उन्मुख सॉफ्टवेयर निर्माण]] में बर्ट्रेंड मेयर द्वारा प्रस्तुत किया गया सुरक्षित अपवाद हैंडलिंग सिद्धांत तब मानता है कि अपवाद होने पर रूटीन केवल दो सार्थक विधि से प्रतिक्रिया कर सकता है:
+[[वस्तु-उन्मुख सॉफ्टवेयर निर्माण]] में बर्ट्रेंड मेयर द्वारा प्रस्तुत किया गया सुरक्षित अपवाद प्रबंधन सिद्धांत तब मानता है कि अपवाद होने पर प्रक्रिया केवल दो सार्थक विधि से प्रतिक्रिया कर सकता है:
-* विफलता, या संगठित आतंक: नित्य वस्तु की स्थिति को अपरिवर्तनीय (यह संगठित भाग है) को फिर से स्थापित करके ठीक करता है, और फिर विफल रहता है (आतंक), इसके कॉलर में एक अपवाद को ट्रिगर करता है (जिससे असामान्य घटना को अनदेखा न किया जा सके) .
+* विफलता, या संगठित आतंक: नित्य वस्तु की स्थिति को अपरिवर्तनीय (यह संगठित भाग है) को फिर से स्थापित करके ठीक करता है, और फिर विफल रहता है (घबड़ाहट), इसके कॉलर में एक अपवाद को ट्रिगर करता है (जिससे असामान्य घटना को अनदेखा न किया जा सके) .
-* पुन: प्रयास करें: दिनचर्या एल्गोरिथम को फिर से आज़माती है, सामान्यतः कुछ मूल्यों को बदलने के बाद जिससे अगले प्रयास में सफल होने का उत्तम  मौका मिले।
+* पुन: प्रयास करें: दिनचर्या एल्गोरिथम को फिर से आज़माती है, सामान्यतः कुछ मूल्यों को बदलने के बाद जिससे अगले प्रयास में सफल होने का उत्तम मौका मिले सकता है।
 विशेष रूप से, केवल एक अपवाद को नज़रअंदाज़ करने की अनुमति नहीं है; एक ब्लॉक को या तो फिर से प्रयास करना चाहिए और सफलतापूर्वक पूरा करना चाहिए, या इसके कॉलर को अपवाद का प्रचार करना चाहिए।
-एफिल सिंटैक्स में व्यक्त एक उदाहरण यहां दिया गया है। यह एक दिनचर्या मानता है {{Eiffel|send_fast}} सामान्यतः संदेश भेजने का उत्तम  विधि होता है, किन्तु यह विफल हो सकता है, अपवाद को ट्रिगर कर सकता है; यदि ऐसा है, तो अगला एल्गोरिथम उपयोग करता है {{Eiffel|send_slow}}, जो कम बार विफल होगा। यदि {{Eiffel|send_slow}} विफल रहता है, दिनचर्या {{Eiffel|send}} पूरी तरह से असफल होना चाहिए, जिससे कॉलर को अपवाद मिल सके।<syntaxhighlight>
+एफिल वाक्य - विन्यास में व्यक्त एक उदाहरण यहां दिया गया है। यह एक दिनचर्या मानता है {{Eiffel|send_fast}} सामान्यतः संदेश भेजने का उत्तम विधि होता है, किन्तु यह विफल हो सकता है, अपवाद को चालू कर सकता है; यदि ऐसा है, तो अगला एल्गोरिथम उपयोग करता है {{Eiffel|send_slow}}, जो कम बार विफल होगा। यदि {{Eiffel|send_slow}} विफल रहता है, दिनचर्या {{Eiffel|send}} पूरी तरह से असफल होना चाहिए, जिससे कॉलर को अपवाद मिल सकता है।<syntaxhighlight>
 send (m: MESSAGE) is
    -- Send m through fast link, if possible, otherwise through slow link.
@@ Line 168: / Line 171: @@
 </syntaxhighlight>
-प्रारंभमें बूलियन स्थानीय चरों को False में इनिशियलाइज़ किया जाता है। यदि  {{Eiffel|send_fast}} विफल रहता है, शरीर ({{Eiffel|do}} क्लॉज) को फिर से निष्पादित किया जाएगा, जिसके निष्पादन का कारण होगा {{Eiffel|send_slow}}. यदि यह निष्पादन {{Eiffel|send_slow}} विफल रहता है, {{Eiffel|rescue}} खंड नहीं के साथ अंत तक निष्पादित होगा {{Eiffel|retry}} (नहीं {{Eiffel|else}} फाइनल में खंड {{Eiffel|if}}), जिससे नियमित निष्पादन पूरी तरह से विफल हो जाता है।
+प्रारंभ में बूलियन स्थानीय चरों को False में आवाक्षरित किया जाता है। यदि {{Eiffel|send_fast}} विफल रहता है, शरीर ({{Eiffel|do}} खंड) को फिर से निष्पादित किया जाएगा, जिसके निष्पादन का कारण होगा {{Eiffel|send_slow}}. यदि यह निष्पादन {{Eiffel|send_slow}} विफल रहता है, {{Eiffel|rescue}} खंड नहीं के साथ अंत तक निष्पादित होगा {{Eiffel|retry}} (नहीं {{Eiffel|else}} फाइनल में खंड {{Eiffel|if}}), जिससे नियमित निष्पादन पूरी तरह से विफल हो जाता है।
-इस दृष्टिकोण में स्पष्ट रूप से परिभाषित करने की योग्यता है कि सामान्य और असामान्य मामले क्या हैं: एक असामान्य मामला, एक अपवाद का कारण बनता है, जिसमें दिनचर्या अपने अनुबंध को पूरा करने में असमर्थ होती है। यह भूमिकाओं के स्पष्ट वितरण को परिभाषित करता है: द {{Eiffel|do}} खंड (सामान्य निकाय) दिनचर्या के अनुबंध को प्राप्त करने, या प्राप्त करने का प्रयास करने का प्रभारी है; {{Eiffel|rescue}} क्लॉज संदर्भ को फिर से स्थापित करने और प्रक्रिया को फिर से प्रारंभिक करने का प्रभारी है, यदि इसमें सफल होने का मौका है, किन्तु कोई वास्तविक गणना करने का नहीं।
+इस दृष्टिकोण में स्पष्ट रूप से परिभाषित करने की योग्यता है कि सामान्य और असामान्य स्थितियों क्या हैं: एक असामान्य मामला, एक अपवाद का कारण बनता है, जिसमें दिनचर्या अपने अनुबंध को पूरा करने में असमर्थ होती है। यह भूमिकाओं के स्पष्ट वितरण को परिभाषित करता है: {{Eiffel|do}} खंड (सामान्य निकाय) दिनचर्या के अनुबंध को प्राप्त करने, या प्राप्त करने का प्रयास करने का प्रभारी है; {{Eiffel|rescue}} क्लॉज संदर्भ को फिर से स्थापित करने और प्रक्रिया को फिर से प्रारंभिक करने का प्रभारी है, यदि इसमें सफल होने का मौका है, किन्तु कोई वास्तविक गणना करने का नहीं।
-चूंकि एफिल में अपवादों का एक स्पष्ट दर्शन है, किनिरी (2006) उनके कार्यान्वयन की आलोचना करता है क्योंकि अपवाद जो भाषा परिभाषा का हिस्सा हैं, वे INTEGER मानों द्वारा दर्शाए जाते हैं, STRING मूल्यों द्वारा डेवलपर-परिभाषित अपवाद। [...] इसके अतिरिक्त, क्योंकि वे मूलभूत मूल्य हैं और वस्तुएं नहीं हैं, उनके पास कोई अंतर्निहित शब्दार्थ नहीं है, जो कि एक सहायक दिनचर्या में व्यक्त किया गया है, जो आवश्यक रूप से प्रभाव में ओवरलोडिंग के प्रतिनिधित्व के कारण मूर्खतापूर्ण नहीं हो सकता है (उदाहरण के लिए, कोई नहीं कर सकता
+चूंकि एफिल में अपवादों का एक स्पष्ट दर्शन है, किनिरी (2006) उनके कार्यान्वयन की आलोचना करता है क्योंकि अपवाद जो भाषा परिभाषा का हिस्सा हैं, वे पूर्णांक मानों द्वारा दर्शाए जाते हैं, स्ट्रिंग मूल्यों द्वारा डेवलपर-परिभाषित अपवाद। [...] इसके अतिरिक्त, क्योंकि वे मूलभूत मान हैं और वस्तुएं नहीं हैं, उनके पास कोई अंतर्निहित शब्दार्थ नहीं है, जो कि एक सहायक दिनचर्या में व्यक्त किया गया है, जो आवश्यक रूप से प्रभाव में अधिक भार के प्रतिनिधित्व के कारण मूर्खतापूर्ण नहीं हो सकता है (उदाहरण के लिए, कोई नहीं कर सकता एक ही मान के दो पूर्णांकों को अलग करें)।<ref name="Kiniry" />
-एक ही मान के दो पूर्णांकों को अलग करें)।<ref name="Kiniry"/>
-=== न आया हुआ अपवाद ===
-अपवाद प्रबंधन रणनीतियों पर विचार करते समय समकालीन अनुप्रयोगों को कई डिज़ाइन चुनौतियों का सामना करना पड़ता है। विशेष रूप से आधुनिक उद्यम स्तर के अनुप्रयोगों में, अपवादों को अधिकांशतः प्रक्रिया की सीमाओं और मशीन की सीमाओं को पार करना चाहिए। एक ठोस अपवाद हैंडलिंग रणनीति को डिजाइन करने का एक हिस्सा यह पहचानना है कि जब कोई प्रक्रिया उस बिंदु तक विफल हो जाती है जहां इसे प्रक्रिया के सॉफ़्टवेयर भाग द्वारा आर्थिक रूप से नियंत्रित नहीं किया जा सकता है।<ref>All Exceptions Are Handled, Jim Wilcox, {{cite web |url=http://granitestatehacker.kataire.com/2008/02/all-exceptions-are-handled.html |title=All Exceptions Are Handled |access-date=2014-12-08 |url-status=live |archive-url=https://web.archive.org/web/20150318100043/http://granitestatehacker.kataire.com/2008/02/all-exceptions-are-handled.html |archive-date=2015-03-18 }}</ref>
-यदि एक अपवाद को फेंक दिया जाता है और पकड़ा नहीं जाता है (परिचालन में, एक अपवाद तब फेंका जाता है जब कोई प्रयुक्त हैंडलर निर्दिष्ट नहीं होता है), न आया हुआ अपवाद रनटाइम द्वारा नियंत्रित किया जाता है; ऐसा करने वाली दिनचर्या कहलाती है{{visible anchor|uncaught exception handler}}.<ref name="cocoa">''Mac Developer Library'', "[https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html Uncaught Exceptions] {{webarchive|url=https://web.archive.org/web/20160304111516/https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html |date=2016-03-04 }}"</ref><ref>''MSDN'', [https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx AppDomain.UnhandledException Event] {{webarchive|url=https://web.archive.org/web/20160304131615/https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx |date=2016-03-04 }}</ref> सबसे आम डिफ़ॉल्ट व्यवहार प्रोग्राम को समाप्त करना और कंसोल पर एक त्रुटि संदेश प्रिंट करना है, सामान्यतः डिबग जानकारी जैसे कि अपवाद का एक स्ट्रिंग प्रतिनिधित्व और [[स्टैक ट्रेस]] सम्मिलित है।<ref name="cocoa" /><ref>''The Python Tutorial'', "[https://docs.python.org/2/tutorial/errors.html 8. Errors and Exceptions] {{webarchive|url=https://web.archive.org/web/20150901043830/https://docs.python.org/2/tutorial/errors.html |date=2015-09-01 }}"</ref><ref>{{cite web|url=http://www.javapractices.com/topic/TopicAction.do?Id=229|title=Java Practices -> Provide an uncaught exception handler|website=www.javapractices.com|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20160909002524/http://www.javapractices.com/topic/TopicAction.do?Id=229|archive-date=9 September 2016}}</ref> यह अधिकांशतः एक शीर्ष-स्तरीय (एप्लिकेशन-स्तर) हैंडलर (उदाहरण के लिए एक [[घटना पाश]] में) होने से बचा जाता है जो अपवादों को रनटाइम तक पहुंचने से पहले पकड़ लेता है।<ref name="cocoa" /><ref name="pmotw">PyMOTW (Python Module Of The Week), "[https://pymotw.com/2/sys/exceptions.html Exception Handling] {{webarchive|url=https://web.archive.org/web/20150915032624/https://pymotw.com/2/sys/exceptions.html |date=2015-09-15 }}"</ref>
-ध्यान दें कि तथापि  एक अनकवर्ड अपवाद के परिणामस्वरूप प्रोग्राम असामान्य रूप से समाप्त हो सकता है (यदि कोई अपवाद पकड़ा नहीं जाता है, विशेष रूप से आंशिक रूप से पूर्ण किए गए लेन-देन को वापस न करने, या संसाधनों को जारी नहीं करने से प्रोग्राम सही नहीं हो सकता है), प्रक्रिया सामान्य रूप से समाप्त हो जाती है (मानते हुए) रनटाइम सही विधि से काम करता है), क्योंकि रनटाइम (जो प्रोग्राम के निष्पादन को नियंत्रित कर रहा है) प्रक्रिया को व्यवस्थित रूप से बंद करना सुनिश्चित कर सकता है।
+=== अनकहा अपवाद ===
+अपवाद प्रबंधन रणनीतियों पर विचार करते समय समकालीन अनुप्रयोगों को कई डिज़ाइन चुनौतियों का सामना करना पड़ता है। विशेष रूप से आधुनिक उद्यम स्तर के अनुप्रयोगों में, अपवादों को अधिकांशतः प्रक्रिया की सीमाओं और मशीन की सीमाओं को पार करना चाहिए। एक ठोस अपवाद प्रबंधन रणनीति को रचना करने का एक हिस्सा यह पहचानना है कि जब कोई प्रक्रिया उस बिंदु तक विफल हो जाती है जहां इसे प्रक्रिया के सॉफ़्टवेयर भाग द्वारा आर्थिक रूप से नियंत्रित नहीं किया जा सकता है।<ref>All Exceptions Are Handled, Jim Wilcox, {{cite web |url=http://granitestatehacker.kataire.com/2008/02/all-exceptions-are-handled.html |title=All Exceptions Are Handled |access-date=2014-12-08 |url-status=live |archive-url=https://web.archive.org/web/20150318100043/http://granitestatehacker.kataire.com/2008/02/all-exceptions-are-handled.html |archive-date=2015-03-18 }}</ref>
-एक बहुप्रचारित कार्यक्रम में, एक थ्रेड में एक बेजोड़ अपवाद के परिणामस्वरूप केवल उस थ्रेड को समाप्त किया जा सकता है, न कि पूरी प्रक्रिया (थ्रेड-लेवल हैंडलर में अनकवर्ड अपवादों को शीर्ष-स्तरीय हैंडलर द्वारा पकड़ा जाता है)। यह सर्वरों के लिए विशेष रूप से महत्वपूर्ण है, जहां उदाहरण के लिए एक [[सर्वलेट]] (अपने स्वयं के धागे में चल रहा है) सर्वर को प्रभावित किए बिना समाप्त किया जा सकता है।
+यदि एक अपवाद को फेंक दिया जाता है और पकड़ा नहीं जाता है (परिचालन में, एक अपवाद तब फेंका जाता है जब कोई प्रयुक्त प्रबंधक निर्दिष्ट नहीं होता है), न आया हुआ अपवाद कार्यविधि द्वारा नियंत्रित किया जाता है; ऐसा करने वाली दिनचर्या कहलाती है {{visible anchor|अनकहा अपवाद संचालक}}.<ref name="cocoa">''Mac Developer Library'', "[https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html Uncaught Exceptions] {{webarchive|url=https://web.archive.org/web/20160304111516/https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html |date=2016-03-04 }}"</ref><ref>''MSDN'', [https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx AppDomain.UnhandledException Event] {{webarchive|url=https://web.archive.org/web/20160304131615/https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx |date=2016-03-04 }}</ref> सबसे आम डिफ़ॉल्ट व्यवहार प्रोग्राम को समाप्त करना और कंसोल पर एक त्रुटि संदेश छपाई करना है, सामान्यतः डिबग जानकारी जैसे कि अपवाद का एक स्ट्रिंग प्रतिनिधित्व और [[स्टैक ट्रेस]] सम्मिलित है।<ref name="cocoa" /><ref>''The Python Tutorial'', "[https://docs.python.org/2/tutorial/errors.html 8. Errors and Exceptions] {{webarchive|url=https://web.archive.org/web/20150901043830/https://docs.python.org/2/tutorial/errors.html |date=2015-09-01 }}"</ref><ref>{{cite web|url=http://www.javapractices.com/topic/TopicAction.do?Id=229|title=Java Practices -> Provide an uncaught exception handler|website=www.javapractices.com|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20160909002524/http://www.javapractices.com/topic/TopicAction.do?Id=229|archive-date=9 September 2016}}</ref> यह अधिकांशतः एक शीर्ष-स्तरीय (एप्लिकेशन-स्तर) प्रबंधक (उदाहरण के लिए एक [[घटना पाश]] में) होने से बचा जाता है जो अपवादों को कार्यविधि तक पहुंचने से पहले पकड़ लेता है।<ref name="cocoa" /><ref name="pmotw">PyMOTW (Python Module Of The Week), "[https://pymotw.com/2/sys/exceptions.html Exception Handling] {{webarchive|url=https://web.archive.org/web/20150915032624/https://pymotw.com/2/sys/exceptions.html |date=2015-09-15 }}"</ref>
-यह डिफ़ॉल्ट बेजोड़ अपवाद हैंडलर ओवरराइड किया जा सकता है, या तो विश्व स्तर पर या प्रति-थ्रेड, उदाहरण के लिए वैकल्पिक लॉगिंग या अनकैप्ड अपवादों की एंड-यूज़र सूची प्रदान करने के लिए, या उन थ्रेड्स को फिर से प्रारंभिक करने के लिए जो अनकवर्ड अपवाद के कारण समाप्त हो जाते हैं। उदाहरण के लिए, जावा में यह सिंगल थ्रेड के लिए किया जाता है <code>[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler- Thread.setUncaughtExceptionHandler]</code> और विश्व स्तर पर के माध्यम से <code>[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler- Thread.setDefaultUncaughtExceptionHandler]</code>; पायथन में यह संशोधित करके किया जाता है <code>[https://docs.python.org/3/library/sys.html#sys.excepthook sys.excepthook]</code>.
+ध्यान दें कि तथापि एक अंशत: अपवाद के परिणामस्वरूप प्रोग्राम असामान्य रूप से समाप्त हो सकता है (यदि कोई अपवाद पकड़ा नहीं जाता है, विशेष रूप से आंशिक रूप से पूर्ण किए गए लेन-देन को वापस न करने, या संसाधनों को जारी नहीं करने से प्रोग्राम सही नहीं हो सकता है), प्रक्रिया सामान्य रूप से समाप्त हो जाती है (मानते हुए) कार्यविधि सही विधि से काम करता है), क्योंकि कार्यविधि (जो प्रोग्राम के निष्पादन को नियंत्रित कर रहा है) प्रक्रिया को व्यवस्थित रूप से बंद करना सुनिश्चित कर सकता है।
+एक बहुप्रचारित कार्यक्रम में, एक कड़ी में एक बेजोड़ अपवाद के परिणामस्वरूप केवल उस कड़ी को समाप्त किया जा सकता है, न कि पूरी प्रक्रिया (कड़ी-लेवल प्रबंधक में अनकवर्ड अपवादों को शीर्ष-स्तरीय प्रबंधक द्वारा पकड़ा जाता है)। यह सर्वरों के लिए विशेष रूप से महत्वपूर्ण है, जहां उदाहरण के लिए एक [[सर्वलेट]] (अपने स्वयं के धागे में चल रहा है) सर्वर को प्रभावित किए बिना समाप्त किया जा सकता है।
+यह डिफ़ॉल्ट बेजोड़ अपवाद प्रबंधक ओवरराइड किया जा सकता है, या तो विश्व स्तर पर या प्रति-कड़ी, उदाहरण के लिए वैकल्पिक लॉगिंग या अनकैप्ड अपवादों की एंड-यूज़र सूची प्रदान करने के लिए, या उन कड़ी्स को फिर से प्रारंभिक करने के लिए जो अनकवर्ड अपवाद के कारण समाप्त हो जाते हैं। उदाहरण के लिए, जावा में यह सिंगल कड़ी के लिए किया जाता है <code>[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler- Thread.setUncaughtExceptionHandler]</code> और विश्व स्तर पर के माध्यम से <code>[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler- Thread.setDefaultUncaughtExceptionHandler]</code>; पायथन में यह संशोधित करके किया जाता है <code>[https://docs.python.org/3/library/sys.html#sys.excepthook sys.excepthook]</code>.
 === चेक किए गए अपवाद ===
-जावा (प्रोग्रामिंग लैंग्वेज) ने चेक किए गए अपवादों की धारणा प्रस्तुत की,<ref>{{cite web |url=http://answers.google.com/answers/threadview?id=26101 |title=Google Answers: The origin of checked exceptions |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110806090553/http://answers.google.com/answers/threadview?id=26101 |archive-date=2011-08-06 }}</ref><ref>Java Language Specification, chapter 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 {{webarchive|url=https://web.archive.org/web/20061208042454/http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html |date=2006-12-08 }}</ref> जो अपवादों के विशेष वर्ग हैं। चेक किए गए अपवाद जो एक विधि उठा सकते हैं, विधि के प्रकार हस्ताक्षर का हिस्सा होना चाहिए। उदाहरण के लिए, यदि कोई विधि फेंक सकती है {{Java|IOException}}, उसे इस तथ्य को अपने विधि हस्ताक्षर में स्पष्ट रूप से घोषित करना चाहिए। ऐसा करने में विफलता संकलन-समय की त्रुटि को जन्म देती है। हंसपेटर मोसेनबॉक के अनुसार, चेक किए गए अपवाद कम सुविधाजनक हैं किन्तु अधिक शक्तिशाली  हैं।<ref>{{cite web
+जावा (प्रोग्रामिंग भाषा) ने चेक किए गए अपवादों की धारणा प्रस्तुत की,<ref>{{cite web |url=http://answers.google.com/answers/threadview?id=26101 |title=Google Answers: The origin of checked exceptions |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110806090553/http://answers.google.com/answers/threadview?id=26101 |archive-date=2011-08-06 }}</ref><ref>Java Language Specification, chapter 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2 {{webarchive|url=https://web.archive.org/web/20061208042454/http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html |date=2006-12-08 }}</ref> जो अपवादों के विशेष वर्ग हैं। चेक किए गए अपवाद जो एक विधि उठा सकते हैं, विधि के प्रकार हस्ताक्षर का हिस्सा होना चाहिए। उदाहरण के लिए, यदि कोई विधि फेंक सकती है {{Java|IOException}}, उसे इस तथ्य को अपने विधि हस्ताक्षर में स्पष्ट रूप से घोषित करना चाहिए। ऐसा करने में विफलता संकलन-समय की त्रुटि को जन्म देती है। हंसपेटर मोसेनबॉक के अनुसार, चेक किए गए अपवाद कम सुविधाजनक हैं किन्तु अधिक शक्तिशाली हैं।<ref>{{cite web
   |access-date  = 2011-08-05
   |date        = 2002-03-25
@@ Line 203: / Line 207: @@
 </ref> चेक किए गए अपवाद, संकलित समय पर, किसी दिए गए एप्लिकेशन में रन टाइम (प्रोग्राम जीवनचक्र चरण) पर बिना क्रिया के अपवादों की घटना को कम कर सकते हैं।
-किनीरी लिखती हैं कि जैसा कि कोई भी जावा प्रोग्रामर जानता है, की मात्रा <code>[[try catch]]</code> एक विशिष्ट जावा एप्लिकेशन में कोड कभी-कभी स्पष्ट औपचारिक पैरामीटर के लिए आवश्यक तुलनीय कोड से बड़ा होता है और अन्य भाषाओं में रिटर्न वैल्यू चेकिंग अपवाद नहीं होता है। वास्तव में, इन-द-ट्रेंच जावा प्रोग्रामर्स के बीच आम सहमति यह है कि चेक किए गए अपवादों से निपटना लगभग उतना ही अप्रिय कार्य है जितना कि प्रलेखन लिखना। इस प्रकार, कई प्रोग्रामर रिपोर्ट करते हैं कि वे अपवादों की "नाराजगी" करते हैं। .<ref name="Kiniry"/>[[मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर)]] ने ... समग्र रूप से लिखा है कि मुझे लगता है कि अपवाद अच्छे हैं, लेकिन जावा द्वारा जांचे गए अपवाद उनके लायक होने की तुलना में अधिक परेशानी वाले हैं।<ref name=Eckel/>2006 तक किसी भी प्रमुख प्रोग्रामिंग भाषा ने चेक किए गए अपवादों को जोड़ने में जावा का अनुसरण नहीं किया।<ref name=Eckel>{{cite book |last1=Eckel |first1=Bruce |title=Thinking in Java |date=2006 |publisher=Prentice Hall |location=Upper Saddle River, NJ |isbn=0-13-187248-6 |pages=347–348 |edition=4th}}</ref> उदाहरण के लिए, सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी # को एरिक गनर्सन द्वारा पोस्ट किए गए निम्नलिखित के साथ किसी अपवाद विनिर्देशों की घोषणा की आवश्यकता नहीं है या अनुमति नहीं है:<ref>{{cite web |last1=Gunnerson |first1=Eric |title=C# and exception specifications |url=http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820|archive-url=https://web.archive.org/web/20060101083304/http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820 |date=9 November 2000|archive-date=1 January 2006|url-status=dead}}</ref><ref name="Kiniry"/><ref name=Eckel/> {{quote|"Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result – decreased productivity and little or no increase in code quality."}}
+किनीरी लिखती हैं कि जैसा कि कोई भी जावा प्रोग्रामर जानता है, की मात्रा <code>[[try catch]]</code> एक विशिष्ट जावा एप्लिकेशन में कोड कभी-कभी स्पष्ट औपचारिक पैरामीटर के लिए आवश्यक तुलनीय कोड से बड़ा होता है और अन्य भाषाओं में रिटर्न वैल्यू चेकिंग अपवाद नहीं होता है। वास्तव में, इन-द-ट्रेंच जावा प्रोग्रामर्स के बीच आम सहमति यह है कि चेक किए गए अपवादों से निपटना लगभग उतना ही अप्रिय कार्य है जितना कि प्रलेखन लिखना। इस प्रकार, कई प्रोग्रामर रिपोर्ट करते हैं कि वे अपवादों की "नाराजगी" करते हैं। .<ref name="Kiniry"/>[[मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर)]] ने ... समग्र रूप से लिखा है कि मुझे लगता है कि अपवाद अच्छे हैं, लेकिन जावा द्वारा जांचे गए अपवाद उनके लायक होने की तुलना में अधिक परेशानी वाले हैं।<ref name=Eckel/>2006 तक किसी भी प्रमुख प्रोग्रामिंग भाषा ने चेक किए गए अपवादों को जोड़ने में जावा का अनुसरण नहीं किया।<ref name=Eckel>{{cite book |last1=Eckel |first1=Bruce |title=Thinking in Java |date=2006 |publisher=Prentice Hall |location=Upper Saddle River, NJ |isbn=0-13-187248-6 |pages=347–348 |edition=4th}}</ref> उदाहरण के लिए, सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी # को एरिक गनर्सन द्वारा पोस्ट किए गए निम्नलिखित के साथ किसी अपवाद विनिर्देशों की घोषणा की आवश्यकता नहीं है या अनुमति नहीं है:<ref>{{cite web |last1=Gunnerson |first1=Eric |title=C# and exception specifications |url=http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820|archive-url=https://web.archive.org/web/20060101083304/http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820 |date=9 November 2000|archive-date=1 January 2006|url-status=dead}}</ref><ref name="Kiniry"/><ref name=Eckel/> {{quote|"छोटे कार्यक्रमों की जांच से यह निष्कर्ष निकलता है कि अपवाद विनिर्देशों की आवश्यकता डेवलपर उत्पादकता और कोड गुणवत्ता दोनों को बढ़ा सकती है, लेकिन बड़े सॉफ्टवेयर परियोजनाओं के साथ अनुभव एक अलग परिणाम सुझाता है - उत्पादकता में कमी और कोड गुणवत्ता में बहुत कम या कोई वृद्धि नहीं।"}}
 [[एंडर्स हेल्सबर्ग]] ने चेक किए गए अपवादों के साथ दो चिंताओं का वर्णन किया है:<ref name=Trouble>{{cite web |url=https://www.artima.com/articles/the-trouble-with-checked-exceptions|title=The Trouble with Checked Exceptions: A Conversation with Anders Hejlsberg, Part II |author1=Bill Venners |author2=[[Bruce Eckel]] |date=August 18, 2003 |access-date=4 January 2022}}</ref>
 * वर्जनिंग: अपवाद एक्स और वाई को फेंकने के लिए एक विधि घोषित की जा सकती है। कोड के बाद के संस्करण में, कोई अपवाद जेड को विधि से नहीं फेंक सकता है, क्योंकि यह नए कोड को पहले के उपयोगों के साथ असंगत बना देगा। चेक किए गए अपवादों के लिए विधि के कॉलर्स को या तो Z को उनके थ्रो क्लॉज में जोड़ने या अपवाद को संभालने की आवश्यकता होती है। वैकल्पिक रूप से, Z को X या Y के रूप में गलत विधि से प्रस्तुत किया जा सकता है।
-* मापनीयता: एक पदानुक्रमित डिजाइन में, प्रत्येक प्रणाली में कई उपप्रणाली हो सकते हैं। प्रत्येक उपप्रणाली कई अपवादों को फेंक सकता है। प्रत्येक पैरेंट प्रणाली को इसके नीचे के सभी उपप्रणाली के अपवादों से निपटना चाहिए, जिसके परिणामस्वरूप अपवादों की एक घातीय संख्या से निपटा जाना चाहिए। चेक किए गए अपवादों के लिए इन सभी अपवादों को स्पष्ट रूप से निपटाए जाने की आवश्यकता होती है।
+* मापनीयता: एक पदानुक्रमित रचना में, प्रत्येक प्रणाली में कई उपप्रणाली हो सकते हैं। प्रत्येक उपप्रणाली कई अपवादों को फेंक सकता है। प्रत्येक जनक प्रणाली को इसके नीचे के सभी उपप्रणाली के अपवादों से निपटना चाहिए, जिसके परिणामस्वरूप अपवादों की एक घातीय संख्या से निपटा जाना चाहिए। चेक किए गए अपवादों के लिए इन सभी अपवादों को स्पष्ट रूप से निपटाए जाने की आवश्यकता होती है।
-इनके आसपास काम करने के लिए, हेजल्सबर्ग का कहना है कि प्रोग्रामर एक का उपयोग करके सुविधा को दरकिनार करने का सहारा लेते हैं {{C++|throws Exception}} घोषणा। एक और धोखा a का उपयोग करना है {{C++|try { ... } catch (Exception e) {<nowiki>}</nowiki>}} हैंडलर।<ref name=Trouble/>इसे पोकेमोन के कैचफ्रेज़ गॉट्टा कैच 'एम ऑल! .<ref>{{cite book |last1=Juneau |first1=Josh |title=Java 9 Recipes: A Problem-Solution Approach |date=31 May 2017 |publisher=Apress |isbn=978-1-4842-1976-8 |page=226 |url=https://www.google.com/books/edition/Java_9_Recipes/TSYmDwAAQBAJ?hl=en&gbpv=1&pg=PA226 |language=en}}</ref> जावा ट्यूटोरियल कैच-ऑल एक्सेप्शन हैंडलिंग को हतोत्साहित करता है क्योंकि यह उन अपवादों को पकड़ सकता है जिनके लिए हैंडलर का इरादा नहीं था।<ref>{{cite web |url=http://download.oracle.com/javase/tutorial/essential/exceptions/advantages.html |title=Advantages of Exceptions (The Java™ Tutorials : Essential Classes : Exceptions) |publisher=Download.oracle.com |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20111026121217/http://download.oracle.com/javase/tutorial/essential/exceptions/advantages.html |archive-date=2011-10-26 }}</ref> फिर भी एक और हतोत्साहित करने वाली चाल सभी अपवादों को उपवर्ग बनाना है {{C++|RuntimeException}}.<ref>{{cite web|url=http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html|title=Unchecked Exceptions – The Controversy (The Java™ Tutorials : Essential Classes : Exceptions)|publisher=Download.oracle.com|archive-url=https://web.archive.org/web/20111117042228/http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html|archive-date=2011-11-17|url-status=live|access-date=2011-12-15}}</ref> एक प्रोत्साहित समाधान कैच-ऑल हैंडलर या थ्रो क्लॉज का उपयोग करना है, किन्तु सामान्य सुपरक्लास के अतिरिक्त सभी संभावित फेंके गए अपवादों के एक विशिष्ट [[सुपरक्लास (कंप्यूटर विज्ञान)]] के साथ {{C++|Exception}}. एक अन्य प्रोत्साहित समाधान अपवाद प्रकारों को परिभाषित और घोषित करना है जो तथाकथित विधि के अमूर्त स्तर के लिए उपयुक्त हैं<ref>Bloch 2001:178 {{cite book | last = Bloch | first = Joshua | year = 2001 | title = Effective Java Programming Language Guide | publisher = Addison-Wesley Professional | isbn = 978-0-201-31005-4 | url-access = registration | url = https://archive.org/details/effectivejavapro00bloc }}</ref> और [[अपवाद श्रृंखलन]] का उपयोग करके निम्न स्तर के अपवादों को इन प्रकारों में मैप करें।
+इनके आसपास काम करने के लिए, हेजल्सबर्ग का कहना है कि प्रोग्रामर एक का उपयोग करके सुविधा को दरकिनार करने का सहारा लेते हैं {{C++|throws Exception}} घोषणा। एक और धोखा a का उपयोग करना है {{C++|try { ... } catch (Exception e) {<nowiki>}</nowiki>}} हैंडलर।<ref name=Trouble/>इसे पोकेमोन के कैचफ्रेज़ गॉट्टा कैच 'एम ऑल! .<ref>{{cite book |last1=Juneau |first1=Josh |title=Java 9 Recipes: A Problem-Solution Approach |date=31 May 2017 |publisher=Apress |isbn=978-1-4842-1976-8 |page=226 |url=https://www.google.com/books/edition/Java_9_Recipes/TSYmDwAAQBAJ?hl=en&gbpv=1&pg=PA226 |language=en}}</ref> जावा शिक्षण सामग्री कैच-ऑल अपवाद प्रबंधन को हतोत्साहित करता है क्योंकि यह उन अपवादों को पकड़ सकता है जिनके लिए प्रबंधक का इरादा नहीं था।<ref>{{cite web |url=http://download.oracle.com/javase/tutorial/essential/exceptions/advantages.html |title=Advantages of Exceptions (The Java™ Tutorials : Essential Classes : Exceptions) |publisher=Download.oracle.com |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20111026121217/http://download.oracle.com/javase/tutorial/essential/exceptions/advantages.html |archive-date=2011-10-26 }}</ref> फिर भी एक और हतोत्साहित करने वाली चाल सभी अपवादों को उपवर्ग बनाना है {{C++|RuntimeException}}.<ref>{{cite web|url=http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html|title=Unchecked Exceptions – The Controversy (The Java™ Tutorials : Essential Classes : Exceptions)|publisher=Download.oracle.com|archive-url=https://web.archive.org/web/20111117042228/http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html|archive-date=2011-11-17|url-status=live|access-date=2011-12-15}}</ref> एक प्रोत्साहित समाधान कैच-ऑल प्रबंधक या थ्रो क्लॉज का उपयोग करना है, किन्तु सामान्य सुपरक्लास के अतिरिक्त सभी संभावित फेंके गए अपवादों के एक विशिष्ट [[सुपरक्लास (कंप्यूटर विज्ञान)]] के साथ {{C++|Exception}}. एक अन्य प्रोत्साहित समाधान अपवाद प्रकारों को परिभाषित और घोषित करना है जो तथाकथित विधि के अमूर्त स्तर के लिए उपयुक्त हैं<ref>Bloch 2001:178 {{cite book | last = Bloch | first = Joshua | year = 2001 | title = Effective Java Programming Language Guide | publisher = Addison-Wesley Professional | isbn = 978-0-201-31005-4 | url-access = registration | url = https://archive.org/details/effectivejavapro00bloc }}</ref> और [[अपवाद श्रृंखलन]] का उपयोग करके निम्न स्तर के अपवादों को इन प्रकारों में मैप करें।
 ==== समान तंत्र ====
-चेक किए गए अपवादों की जड़ें [[सीएलयू प्रोग्रामिंग भाषा]] के अपवाद विनिर्देशन की धारणा पर वापस जाती हैं।<ref name=Mindview/>एक फ़ंक्शन केवल इसके प्रकार में सूचीबद्ध अपवादों को बढ़ा सकता है, किन्तु कॉल किए गए कार्यों से किसी भी लीक अपवाद को स्वचालित रूप से एकमात्र रनटाइम अपवाद में बदल दिया जाएगा, {{code|failure}}, संकलन-समय त्रुटि के परिणामस्वरूप।<ref name="CLU">{{cite journal |last1=Liskov |first1=B.H. |last2=Snyder |first2=A. |title=Exception Handling in CLU |journal=IEEE Transactions on Software Engineering |date=November 1979 |volume=SE-5 |issue=6 |pages=546–558 |doi=10.1109/TSE.1979.230191 |s2cid=15506879 |url=http://csg.csail.mit.edu/CSGArchives/memos/Memo-155-3.pdf |access-date=19 December 2021}}</ref> बाद में [[मॉड्यूल -3]] में भी ऐसा ही फीचर था।<ref>{{cite web |url=http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |title=Modula-3 - Procedure Types |publisher=.cs.columbia.edu |date=1995-03-08 |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20080509143753/http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |archive-date=2008-05-09 }}</ref> इन सुविधाओं में संकलित समय जांच सम्मिलित नहीं है जो चेक किए गए अपवादों की अवधारणा में केंद्रीय है।<ref name=Mindview>{{cite web |url=http://www.mindview.net/Etc/Discussions/CheckedExceptions |archive-url=https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions |url-status=dead |archive-date=2002-04-05 |title=Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions? |publisher=Mindview.net |access-date=2011-12-15 }}</ref>
+चेक किए गए अपवादों की जड़ें [[सीएलयू प्रोग्रामिंग भाषा]] के अपवाद विनिर्देशन की धारणा पर वापस जाती हैं।<ref name=Mindview/> फलन केवल इसके प्रकार में सूचीबद्ध अपवादों को बढ़ा सकता है, किन्तु पुकारे गए कार्यों से किसी भी रिसाव अपवाद को स्वचालित रूप से एकमात्र रनटाइम अपवाद में बदल दिया जाएगा, {{code|failure}}, संकलन-समय त्रुटि के परिणाम स्वरूप।<ref name="CLU">{{cite journal |last1=Liskov |first1=B.H. |last2=Snyder |first2=A. |title=Exception Handling in CLU |journal=IEEE Transactions on Software Engineering |date=November 1979 |volume=SE-5 |issue=6 |pages=546–558 |doi=10.1109/TSE.1979.230191 |s2cid=15506879 |url=http://csg.csail.mit.edu/CSGArchives/memos/Memo-155-3.pdf |access-date=19 December 2021}}</ref> बाद में [[मॉड्यूल -3]] में भी ऐसा ही विशेषता थी।<ref>{{cite web |url=http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |title=Modula-3 - Procedure Types |publisher=.cs.columbia.edu |date=1995-03-08 |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20080509143753/http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |archive-date=2008-05-09 }}</ref> इन सुविधाओं में संकलित समय जांच सम्मिलित नहीं है जो चेक किए गए अपवादों की अवधारणा में केंद्रीय है।<ref name=Mindview>{{cite web |url=http://www.mindview.net/Etc/Discussions/CheckedExceptions |archive-url=https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions |url-status=dead |archive-date=2002-04-05 |title=Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions? |publisher=Mindview.net |access-date=2011-12-15 }}</ref>
-सी ++ प्रोग्रामिंग भाषा के प्रारंभिक संस्करणों में चेक किए गए अपवादों के समान एक वैकल्पिक तंत्र सम्मिलित था, जिसे अपवाद विनिर्देश कहा जाता है। डिफ़ॉल्ट रूप से कोई भी फ़ंक्शन कोई अपवाद फेंक सकता है, किन्तु इसे सीमित किया जा सकता है {{Cpp|throw}} फ़ंक्शन सिग्नेचर में क्लॉज़ जोड़ा गया, जो निर्दिष्ट करता है कि फ़ंक्शन कौन से अपवाद फेंक सकता है। संकलन-समय पर अपवाद विनिर्देशों को प्रयुक्त नहीं किया गया था। उल्लंघन के परिणामस्वरूप वैश्विक कार्य हुआ {{Cpp|std::unexpected}} बुलाया जाना।<ref name="bjarne-exc">[[Bjarne Stroustrup]], ''[[The C++ Programming Language]]'' Third Edition, [[Addison Wesley]], 1997. {{ISBN|0-201-88954-4}}. pp. 375-380.</ref> एक खाली अपवाद विनिर्देश दिया जा सकता है, जो इंगित करता है कि फ़ंक्शन कोई अपवाद नहीं फेंकेगा। अपवाद प्रबंधन को भाषा में जोड़े जाने पर इसे डिफ़ॉल्ट नहीं बनाया गया था क्योंकि इसके लिए वर्तमान कोड में बहुत अधिक संशोधन की आवश्यकता होगी, अन्य भाषाओं में लिखे गए कोड के साथ बातचीत बाधित होगी, और प्रोग्रामर को स्थानीय स्तर पर बहुत सारे हैंडलर लिखने के लिए लुभाएगा। स्तर।<ref name="bjarne-exc" />खाली अपवाद विनिर्देशों का स्पष्ट उपयोग, चूंकि, सी ++ कंपाइलर्स को महत्वपूर्ण कोड और स्टैक लेआउट ऑप्टिमाइज़ेशन करने की अनुमति दे सकता है जो किसी फ़ंक्शन में अपवाद हैंडलिंग हो सकता है।<ref name="cppeh" />  कुछ विश्लेषकों ने सी ++ में अपवाद विनिर्देशों के उचित उपयोग को प्राप्त करना कठिनाई माना।<ref>{{cite journal | title=Ten Guidelines for Exception Specifications | last=Reeves | first= J.W. | journal=C++ Report | volume=8 | issue=7 |date=July 1996}}</ref> अपवाद विनिर्देशों का यह उपयोग [[C++98]] और [[C++03]] में सम्मिलित किया गया था, जिसे 2012 C++ भाषा मानक ([[C++11]]) में बहिष्कृत किया गया था,<ref>{{cite web |url=http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |title=Trip Report: March 2010 ISO C++ Standards Meeting |last=Sutter |first=Herb |author-link=Herb Sutter |date=3 March 2010 |access-date=24 March 2010 |url-status=live |archive-url=https://web.archive.org/web/20100323082634/http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |archive-date=23 March 2010 }}</ref> और भाषा से C++ 17 में हटा दिया गया था। एक फ़ंक्शन जो किसी भी अपवाद को नहीं फेंकेगा, अब इसके द्वारा निरूपित किया जा सकता है {{Cpp|noexcept}} कीवर्ड।
+C++ प्रोग्रामिंग भाषा के प्रारंभिक संस्करणों में चेक किए गए अपवादों के समान एक वैकल्पिक तंत्र सम्मिलित था, जिसे अपवाद विनिर्देश कहा जाता है। गलत रूप से कोई भी फलन कोई अपवाद प्रक्षेपण सकता है, किन्तु इसे सीमित किया जा सकता है {{Cpp|throw}} फलन हस्ताक्षर में खंड जोड़ा गया, जो निर्दिष्ट करता है कि फलन कौन से अपवाद प्रक्षेपण सकता है। संकलन-समय पर अपवाद विनिर्देशों को प्रयुक्त नहीं किया गया था। उल्लंघन के परिणाम स्वरूप वैश्विक कार्य हुआ {{Cpp|std::unexpected}} बुलाया जाना।<ref name="bjarne-exc">[[Bjarne Stroustrup]], ''[[The C++ Programming Language]]'' Third Edition, [[Addison Wesley]], 1997. {{ISBN|0-201-88954-4}}. pp. 375-380.</ref> एक खाली अपवाद विनिर्देश दिया जा सकता है, जो इंगित करता है कि फलन कोई अपवाद नहीं फेंकेगा। अपवाद प्रबंधन को भाषा में जोड़े जाने पर इसे डिफ़ॉल्ट नहीं बनाया गया था क्योंकि इसके लिए वर्तमान कोड में बहुत अधिक संशोधन की आवश्यकता होगी, अन्य भाषाओं में लिखे गए कोड के साथ बातचीत अवरोधित होगी, और प्रोग्रामर को स्थानीय स्तर पर बहुत सारे प्रबंधक लिखने के लिए लुभाएगा। स्तर।<ref name="bjarne-exc" /> खाली अपवाद विनिर्देशों का स्पष्ट उपयोग, चूंकि, C++ संकलनकर्ता को महत्वपूर्ण कोड और स्टैक लेआउट अनुकूलन करने की अनुमति दे सकता है जो किसी फलन में अपवाद प्रबंधन हो सकता है।<ref name="cppeh" /> कुछ विश्लेषकों ने C++ में अपवाद विनिर्देशों के उचित उपयोग को प्राप्त करना कठिनाई माना।<ref>{{cite journal | title=Ten Guidelines for Exception Specifications | last=Reeves | first= J.W. | journal=C++ Report | volume=8 | issue=7 |date=July 1996}}</ref> अपवाद विनिर्देशों का यह उपयोग [[C++98]] और [[C++03]] में सम्मिलित किया गया था, जिसे 2012 C++ भाषा मानक ([[C++11]]) में बहिष्कृत किया गया था,<ref>{{cite web |url=http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |title=Trip Report: March 2010 ISO C++ Standards Meeting |last=Sutter |first=Herb |author-link=Herb Sutter |date=3 March 2010 |access-date=24 March 2010 |url-status=live |archive-url=https://web.archive.org/web/20100323082634/http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |archive-date=23 March 2010 }}</ref> और भाषा से C++ 17 में हटा दिया गया था। एक फलन जो किसी भी अपवाद को नहीं फेंकेगा, अब {{Cpp|noexcept}}कुंजीशब्द द्वारा निरूपित किया जा सकता है।
-OCaml प्रोग्रामिंग भाषा के लिए एक बेजोड़ अपवाद विश्लेषक उपस्थित है।<ref>{{cite web |url=http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm |title=OcamlExc - An uncaught exceptions analyzer for Objective Caml |publisher=Caml.inria.fr |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110806090555/http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm |archive-date=2011-08-06 }}</ref> उपकरण विस्तारित प्रकार के हस्ताक्षर के रूप में उठाए गए अपवादों के समुच्चय की सूची करता है। लेकिन, चेक किए गए अपवादों के विपरीत, टूल को किसी सिंटैक्टिक एनोटेशन की आवश्यकता नहीं होती है और यह बाहरी है (अर्थात अपवादों की जांच किए बिना प्रोग्राम को संकलित करना और चलाना संभव है)।
+ओ कैमल प्रोग्रामिंग भाषा के लिए एक बेजोड़ अपवाद विश्लेषक उपस्थित है।<ref>{{cite web |url=http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm |title=OcamlExc - An uncaught exceptions analyzer for Objective Caml |publisher=Caml.inria.fr |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110806090555/http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm |archive-date=2011-08-06 }}</ref> उपकरण विस्तारित प्रकार के हस्ताक्षर के रूप में उठाए गए अपवादों के समुच्चय की सूची करता है। लेकिन, चेक किए गए अपवादों के विपरीत, उपकरण को किसी वाक्यात्मक टिप्पणी की आवश्यकता नहीं होती है और यह बाहरी है (अर्थात अपवादों की जांच किए बिना प्रोग्राम को संकलित करना और चलाना संभव है)।
 === अपवादों की गतिशील जाँच ===
-अपवाद हैंडलिंग रूटीन का बिंदु यह सुनिश्चित करना है कि कोड त्रुटि स्थितियों को संभाल सकता है। यह स्थापित करने के लिए कि अपवाद प्रबंधन रूटीन पर्याप्त रूप से शक्तिशाली  हैं, कोड को अमान्य या अप्रत्याशित इनपुट के विस्तृत स्पेक्ट्रम के साथ प्रस्तुत करना आवश्यक है, जैसे कि सॉफ्टवेयर [[दोष इंजेक्शन]] और म्यूटेशन परीक्षण के माध्यम से बनाया जा सकता है (जिसे कभी-कभी फ़ज़ भी कहा जाता है) परिक्षण)। सबसे कठिन प्रकार के सॉफ़्टवेयर में से एक जिसके लिए अपवाद हैंडलिंग रूटीन लिखना है, प्रोटोकॉल सॉफ़्टवेयर है, क्योंकि इनपुट प्राप्त करने के लिए एक शक्तिशाली  प्रोटोकॉल कार्यान्वयन तैयार होना चाहिए जो प्रासंगिक विनिर्देश (नों) का अनुपालन नहीं करता है।
+अपवाद प्रबंधन प्रक्रिया का बिंदु यह सुनिश्चित करना है कि कोड त्रुटि स्थितियों को संभाल सकता है। यह स्थापित करने के लिए कि अपवाद प्रबंधन प्रक्रिया पर्याप्त रूप से शक्तिशाली हैं, कोड को अमान्य या अप्रत्याशित इनपुट के विस्तृत स्पेक्ट्रम के साथ प्रस्तुत करना आवश्यक है, जैसे कि सॉफ्टवेयर [[दोष इंजेक्शन]] और म्यूटेशन परीक्षण के माध्यम से बनाया जा सकता है (इसे कभी-कभी फ़ज़ परीक्षण भी कहा जाता है) सबसे कठिन प्रकार के सॉफ़्टवेयर में से एक जिसके लिए अपवाद प्रबंधन प्रक्रिया लिखना है, प्रोटोकॉल सॉफ़्टवेयर है, क्योंकि इनपुट प्राप्त करने के लिए एक शक्तिशाली प्रोटोकॉल कार्यान्वयन तैयार होना चाहिए| जो प्रासंगिक विनिर्देश (नों) का अनुपालन नहीं करता है।
-यह सुनिश्चित करने के लिए कि एक [[सॉफ्टवेयर विकास प्रक्रिया]] के समय सार्थक प्रतिगमन विश्लेषण किया जा सकता है, किसी भी अपवाद से निपटने का परीक्षण अत्यधिक स्वचालित होना चाहिए, और परीक्षण स्थितियोंं को एक वैज्ञानिक, दोहराने योग्य फैशन में उत्पन्न किया जाना चाहिए। कई व्यावसायिक रूप से उपलब्ध प्रणालियाँ उपस्थित हैं जो इस तरह के परीक्षण करती हैं।
+यह सुनिश्चित करने के लिए कि एक [[सॉफ्टवेयर विकास प्रक्रिया]] के समय सार्थक प्रतिगमन विश्लेषण किया जा सकता है, किसी भी अपवाद से निपटने का परीक्षण अत्यधिक स्वचालित होना चाहिए, और परीक्षण स्थितियोंं को एक वैज्ञानिक, दोहराने योग्य विधान में उत्पन्न किया जाना चाहिए। कई व्यावसायिक रूप से उपलब्ध प्रणालियाँ उपस्थित हैं जो इस तरह के परीक्षण करती हैं।
-जावा (प्रोग्रामिंग लैंग्वेज) या .NET फ्रेमवर्क | .NET जैसे रनटाइम इंजन वातावरण में, ऐसे उपकरण उपस्थित हैं जो रनटाइम इंजन से जुड़ते हैं और हर बार जब कोई अपवाद होता है, तो वे डिबगिंग जानकारी रिकॉर्ड करते हैं जो उस समय मेमोरी में उपस्थित थी अपवाद फेंक दिया गया था (कॉल स्टैक और हीप (डेटा संरचना) मान)। इन उपकरणों को स्वचालित अपवाद प्रबंधन या त्रुटि अवरोधन उपकरण कहा जाता है और अपवादों के लिए 'मूल-कारण' जानकारी प्रदान करते हैं।
+जावा (प्रोग्रामिंग भाषा) या .नेट फ्रेमवर्क | .नेट जैसे कार्यावधि इंजन वातावरण में, ऐसे उपकरण उपस्थित हैं जो कार्यावधि इंजन से जुड़ते हैं और हर बार जब कोई अपवाद होता है, तो वे डिबगिंग जानकारी अभिलेख करते हैं जो उस समय मेमोरी में उपस्थित थी अपवाद फेंक दिया गया था (कॉल स्टैक और हीप (डेटा संरचना) मान)। इन उपकरणों को स्वचालित अपवाद प्रबंधन या त्रुटि अवरोधन उपकरण कहा जाता है और अपवादों के लिए 'मूल-कारण' जानकारी प्रदान करते हैं।
 === अतुल्यकालिक अपवाद ===
-एसिंक्रोनस अपवाद एक अलग थ्रेड या बाहरी प्रक्रिया द्वारा उठाए गए इवेंट हैं, जैसे किसी प्रोग्राम को बाधित करने के लिए [[नियंत्रण-सी]]|Ctrl-C को दबाना, सिग्नल प्राप्त करना (कंप्यूटिंग), या किसी अन्य थ्रेड (कंप्यूटर) से स्टॉप या सस्पेंड जैसे विघटनकारी संदेश भेजना विज्ञान)।<ref>{{cite web |url=http://citeseer.ist.psu.edu/415348.html |title=Asynchronous Exceptions in Haskell - Marlow, Jones, Moran (ResearchIndex) |publisher=Citeseer.ist.psu.edu |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110223164151/http://citeseer.ist.psu.edu/415348.html |archive-date=2011-02-23 }}</ref><ref>{{cite journal|url=http://www.cs.williams.edu/~freund/papers/python.pdf |title=Safe Asynchronous Exceptions For Python |access-date=4 January 2022 |first1=Stephen N.|last1=Freund|first2=Mark P.|last2=Mitchell }}</ref> जबकि तुल्यकालिक अपवाद एक विशिष्ट पर होता है <code>throw</code> बयान, अतुल्यकालिक अपवाद किसी भी समय उठाया जा सकता है। यह इस प्रकार है कि अतुल्यकालिक अपवाद हैंडलिंग को संकलक द्वारा अनुकूलित नहीं किया जा सकता है, क्योंकि यह अतुल्यकालिक अपवादों की अनुपस्थिति को सिद्ध नहीं कर सकता है। उन्हें सही ढंग से प्रोग्राम करना भी कठिनाई है, क्योंकि संसाधन लीक से बचने के लिए सफाई कार्यों के समय अतुल्यकालिक अपवादों को अवरुद्ध किया जाना चाहिए।
+अतुल्यकालिक अपवाद एक अलग कड़ी या बाहरी प्रक्रिया द्वारा उठाए गए आयोजन हैं, जैसे किसी प्रोग्राम को अवरोधित करने के लिए [[नियंत्रण-सी|नियंत्रण-c]] |नियंत्रण-C को दबाना,संकेत प्राप्त करना (कंप्यूटिंग), या किसी अन्य कड़ी (कंप्यूटर) से रुकना या निलंबित जैसे विघटनकारी संदेश भेजना विज्ञान)।<ref>{{cite web |url=http://citeseer.ist.psu.edu/415348.html |title=Asynchronous Exceptions in Haskell - Marlow, Jones, Moran (ResearchIndex) |publisher=Citeseer.ist.psu.edu |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110223164151/http://citeseer.ist.psu.edu/415348.html |archive-date=2011-02-23 }}</ref><ref>{{cite journal|url=http://www.cs.williams.edu/~freund/papers/python.pdf |title=Safe Asynchronous Exceptions For Python |access-date=4 January 2022 |first1=Stephen N.|last1=Freund|first2=Mark P.|last2=Mitchell }}</ref> जबकि तुल्यकालिक <code>throw</code> अपवाद एक विशिष्ट पर होता है, अतुल्यकालिक अपवाद किसी भी समय उठाया जा सकता है। यह इस प्रकार है कि अतुल्यकालिक अपवाद प्रबंधन को संकलक द्वारा अनुकूलित नहीं किया जा सकता है, क्योंकि यह अतुल्यकालिक अपवादों की अनुपस्थिति को सिद्ध नहीं कर सकता है। उन्हें सही ढंग से प्रोग्राम करना भी कठिनाई है, क्योंकि संसाधन रिसाव से बचने के लिए सफाई कार्यों के समय अतुल्यकालिक अपवादों को अवरुद्ध किया जाना चाहिए।
-प्रोग्रामिंग लैंग्वेज सामान्यतः अतुल्यकालिक अपवाद हैंडलिंग से बचती हैं या प्रतिबंधित करती हैं, उदाहरण के लिए C ++ सिग्नल हैंडलर से अपवादों को बढ़ाने से मना करती है, और जावा ने अपने थ्रेडडेथ अपवाद के उपयोग को हटा दिया है जिसका उपयोग एक थ्रेड को दूसरे को रोकने के लिए किया गया था।<ref>{{cite web |url=http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |title=Java Thread Primitive Deprecation |publisher=Java.sun.com |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20090426200153/http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |archive-date=2009-04-26 }}</ref> एक अन्य विशेषता एक अर्ध-अतुल्यकालिक तंत्र है जो केवल कार्यक्रम के कुछ संचालन के समय एक अतुल्यकालिक अपवाद उठाता है। उदाहरण के लिए जावा का {{C++|Thread.interrupt()}} केवल थ्रेड को प्रभावित करता है जब थ्रेड एक ऑपरेशन को कॉल करता है जो फेंकता है {{C++|InterruptedException}}.<ref>{{cite web |title=Interrupts (The Java™ Tutorials > Essential Java Classes > Concurrency) |url=https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html |website=docs.oracle.com |access-date=5 January 2022}}</ref> समान पॉज़िक्स {{C++|pthread_cancel}} एपीआई में दौड़ की स्थिति है जो इसे सुरक्षित रूप से उपयोग करना असंभव बनाती है।<ref>{{cite web |last1=Felker |first1=Rich |title=Thread cancellation and resource leaks |url=http://ewontfix.com/2/ |website=ewontfix.com|access-date=5 January 2022}}</ref>
+प्रोग्रामिंग भाषा सामान्यतः अतुल्यकालिक अपवाद प्रबंधन से बचती हैं या प्रतिबंधित करती हैं, उदाहरण के लिए C ++ सिग्नल प्रबंधक से अपवादों को बढ़ाने से मना करती है, और जावा ने अपने थ्रेडडेथ अपवाद के उपयोग को हटा दिया है जिसका उपयोग एक कड़ी को दूसरे को रोकने के लिए किया गया था।<ref>{{cite web |url=http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |title=Java Thread Primitive Deprecation |publisher=Java.sun.com |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20090426200153/http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |archive-date=2009-04-26 }}</ref> अन्य विशेषता एक अर्ध-अतुल्यकालिक तंत्र है जो केवल कार्यक्रम के कुछ संचालन के समय एक अतुल्यकालिक अपवाद उठाता है। उदाहरण के लिए जावा का {{C++|Thread.interrupt()}} केवल कड़ी को प्रभावित करता है जब कड़ी {{C++|InterruptedException}}को फेंकने वाले ऑपरेशन को कॉल करता है.<ref>{{cite web |title=Interrupts (The Java™ Tutorials > Essential Java Classes > Concurrency) |url=https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html |website=docs.oracle.com |access-date=5 January 2022}}</ref> समान पॉज़िक्स {{C++|pthread_cancel}} एपीआई में दौड़ की स्थिति है जो इसे सुरक्षित रूप से उपयोग करना असंभव बनाती है।<ref>{{cite web |last1=Felker |first1=Rich |title=Thread cancellation and resource leaks |url=http://ewontfix.com/2/ |website=ewontfix.com|access-date=5 January 2022}}</ref>
+=== [[हालत प्रणाली|स्थिति प्रणाली]] ===
+कॉमन लिस्प, [[डायलन (प्रोग्रामिंग भाषा)]] और स्मॉलटाक में एक स्थिति प्रणाली है<ref>{{cite web|author = What Conditions (Exceptions) are Really About|url = http://danweinreb.org/blog/what-conditions-exceptions-are-really-about|title = What Conditions (Exceptions) are Really About|publisher = Danweinreb.org|date = 2008-03-24|access-date = 2014-09-18|url-status = dead|archive-url = https://web.archive.org/web/20130201124021/http://danweinreb.org/blog/what-conditions-exceptions-are-really-about|archive-date = February 1, 2013}}</ref> (कॉमन लिस्प या स्थिति प्रणाली देखें) जिसमें उपरोक्त अपवाद प्रबंधन प्रणाली सम्मिलित हैं। उन भाषाओं या परिवेशों में एक स्थिति का आगमन ([[केंट पिटमैन]] के अनुसार एक त्रुटि का सामान्यीकरण) एक फलन कॉल का अर्थ है, और केवल अपवाद प्रबंधक में देर से स्टैक को खोलने का निर्णय लिया जा सकता है।
-=== [[हालत प्रणाली]] ===
+स्थिति अपवादों का एक सामान्यीकरण हैं। जब कोई स्थिति उत्पन्न होती है, तो स्थिति को संभालने के लिए स्टैक आदेश में उपयुक्त स्थिति प्रबंधक की खोज की जाती है और उसका चयन किया जाता है। ऐसी स्थितियाँ जो त्रुटियों का प्रतिनिधित्व नहीं करती हैं, सुरक्षित रूप से पूरी तरह से असंचालित हो सकती हैं; उनका एकमात्र उद्देश्य उपयोगकर्ता को संकेत या चेतावनी देना हो सकता है।<ref>{{cite web |url=http://www.franz.com/support/documentation/6.2/ansicl/section/conditio.htm |title=Condition System Concepts |publisher=Franz.com |date=2009-07-21 |access-date=2011-12-15 |archive-url=https://web.archive.org/web/20070628213221/http://www.franz.com/support/documentation/6.2/ansicl/section/conditio.htm |archive-date=2007-06-28 |url-status=dead }}</ref>
-कॉमन लिस्प, [[डायलन (प्रोग्रामिंग भाषा)]] और स्मॉलटाक में एक कंडीशन प्रणाली है<ref>{{cite web|author = What Conditions (Exceptions) are Really About|url = http://danweinreb.org/blog/what-conditions-exceptions-are-really-about|title = What Conditions (Exceptions) are Really About|publisher = Danweinreb.org|date = 2008-03-24|access-date = 2014-09-18|url-status = dead|archive-url = https://web.archive.org/web/20130201124021/http://danweinreb.org/blog/what-conditions-exceptions-are-really-about|archive-date = February 1, 2013}}</ref> (कॉमन लिस्प या कंडीशन प्रणाली देखें) जिसमें उपरोक्त अपवाद हैंडलिंग प्रणाली सम्मिलित हैं। उन भाषाओं या परिवेशों में एक स्थिति का आगमन ([[केंट पिटमैन]] के अनुसार एक त्रुटि का सामान्यीकरण) एक फ़ंक्शन कॉल का अर्थ है, और केवल अपवाद हैंडलर में देर से स्टैक को खोलने का निर्णय लिया जा सकता है।
-शर्तें अपवादों का एक सामान्यीकरण हैं। जब कोई स्थिति उत्पन्न होती है, तो स्थिति को संभालने के लिए स्टैक ऑर्डर में उपयुक्त स्थिति हैंडलर की खोज की जाती है और उसका चयन किया जाता है। ऐसी स्थितियाँ जो त्रुटियों का प्रतिनिधित्व नहीं करती हैं, सुरक्षित रूप से पूरी तरह से असंचालित हो सकती हैं; उनका एकमात्र उद्देश्य उपयोगकर्ता को संकेत या चेतावनी देना हो सकता है।<ref>{{cite web |url=http://www.franz.com/support/documentation/6.2/ansicl/section/conditio.htm |title=Condition System Concepts |publisher=Franz.com |date=2009-07-21 |access-date=2011-12-15 |archive-url=https://web.archive.org/web/20070628213221/http://www.franz.com/support/documentation/6.2/ansicl/section/conditio.htm |archive-date=2007-06-28 |url-status=dead }}</ref>
 ==== निरंतर अपवाद ====
-यह अपवाद प्रबंधन के तथाकथित पुनर्जीवन मॉडल से संबंधित है, जिसमें कुछ अपवादों को निरंतर कहा जाता है: हैंडलर में सुधारात्मक कार्रवाई करने के बाद, अपवाद को संकेत देने वाले अभिव्यक्ति पर लौटने की अनुमति है। हालत प्रणाली इस प्रकार सामान्यीकृत है: एक गैर-गंभीर स्थिति (उर्फ निरंतर अपवाद) के हैंडलर के अंदर, पूर्वनिर्धारित पुनरारंभ बिंदुओं (उर्फ पुनरारंभ) पर कूदना संभव है जो सिग्नलिंग अभिव्यक्ति और स्थिति हैंडलर के बीच स्थित है। पुनरारंभ कुछ शाब्दिक वातावरण पर बंद कार्य हैं, जिससे प्रोग्रामर को स्थिति हैंडलर से पूरी तरह से बाहर निकलने या स्टैक को आंशिक रूप से खोलने से पहले इस वातावरण की मरम्मत करने की अनुमति मिलती है।
+यह अपवाद प्रबंधन के तथाकथित पुनर्जीवन मॉडल से संबंधित है, जिसमें कुछ अपवादों को निरंतर कहा जाता है: प्रबंधक में सुधारात्मक कार्रवाई करने के बाद, अपवाद को संकेत देने वाले अभिव्यक्ति पर लौटने की अनुमति है। हालत प्रणाली इस प्रकार सामान्यीकृत है: एक गैर-गंभीर स्थिति (उर्फ निरंतर अपवाद) के प्रबंधक के अंदर, पूर्वनिर्धारित पुनरारंभ बिंदुओं (या पुनरारंभ) पर कूदना संभव है जो संकेतनअभिव्यक्ति और स्थिति प्रबंधक के बीच स्थित है। पुनरारंभ कुछ शाब्दिक वातावरण पर बंद कार्य हैं, जिससे प्रोग्रामर को स्थिति प्रबंधक से पूरी तरह से बाहर निकलने या स्टैक को आंशिक रूप से खोलने से पहले इस वातावरण की मरम्मत करने की अनुमति मिलती है।
-एक उदाहरण PL/I में 'ENDPAGE' स्थिति है; ऑन यूनिट अगले पेज के लिए पेज ट्रेलर लाइन और हेडर लाइन लिख सकती है, फिर बाधित कोड के निष्पादन को फिर से प्रारंभिक करने के लिए गिर सकती है।
+एक उदाहरण पीएल/आई में 'आखरीपन्ना ' स्थिति है; ऑन इकाई अगले पेज के लिए पेज अनुयान लाइन और हेडर लाइन लिख सकती है, फिर अवरोधित कोड के निष्पादन को फिर से प्रारंभिक करने के लिए गिर सकती है।
 ==== पॉलिसी से अलग मैकेनिज्म को फिर से प्रारंभिक करता है ====
-इसके अतिरिक्त स्थिति प्रबंधन [[नीति]] से तंत्र को अलग करता है। पुनर्प्रारंभ त्रुटि से उबरने के लिए विभिन्न संभावित तंत्र प्रदान करता है, किन्तु किसी भी स्थिति में उपयुक्त तंत्र का चयन न करें। वह हालत हैंडलर का प्रांत है, जो (चूंकि यह उच्च-स्तरीय कोड में स्थित है) के पास व्यापक दृश्य तक पहुंच है।
+इसके अतिरिक्त स्थिति प्रबंधन [[नीति]] से तंत्र को अलग करता है। पुनर्प्रारंभ त्रुटि से उबरने के लिए विभिन्न संभावित तंत्र प्रदान करता है, किन्तु किसी भी स्थिति में उपयुक्त तंत्र का चयन न करें। वह हालत प्रबंधक का प्रांत है, जो (चूंकि यह उच्च-स्तरीय कोड में स्थित है) के पास व्यापक दृश्य तक पहुंच है।
-एक उदाहरण: मान लीजिए कि एक लाइब्रेरी फ़ंक्शन है जिसका उद्देश्य एकल [[syslog]] फ़ाइल प्रविष्टि को पार्स करना है। यदि प्रविष्टि विकृत है तो यह कार्य क्या करेगा? कोई एक सही उत्तर नहीं है, क्योंकि एक ही पुस्तकालय को कई अलग-अलग उद्देश्यों के लिए कार्यक्रमों में नियत किया जा सकता है। एक इंटरएक्टिव लॉग-फाइल ब्राउज़र में, सही काम यह हो सकता है कि प्रविष्टि को बिना पार्स किए वापस कर दिया जाए, जिससे उपयोगकर्ता इसे देख सके - किन्तु एक स्वचालित लॉग-सारांश कार्यक्रम में, सही काम करने के लिए शून्य मानों की आपूर्ति करना हो सकता है। अपठनीय फ़ील्ड, किन्तु एक त्रुटि के साथ निरस्त करें, यदि बहुत अधिक प्रविष्टियाँ विकृत की गई हैं।
+उदाहरण: मान लीजिए कि एक पुस्तकालय है जिसका उद्देश्य एकल [[syslog|सिसलोग]] फ़ाइल प्रविष्टि कि व्याख्या करना है। यदि प्रविष्टि विकृत है तो यह कार्य क्या करेगा? कोई एक सही उत्तर नहीं है, क्योंकि एक ही पुस्तकालय को कई अलग-अलग उद्देश्यों के लिए कार्यक्रमों में नियत किया जा सकता है। इंटरएक्टिव लॉग-फाइल ब्राउज़र में, सही काम यह हो सकता है कि प्रविष्टि को बिना पार्स किए वापस कर दिया जाए, जिससे उपयोगकर्ता इसे देख सके - किन्तु एक स्वचालित लॉग-सारांश कार्यक्रम में, सही काम करने के लिए शून्य मानों की आपूर्ति करना हो सकता है। अपठनीय क्षेत्र, किन्तु एक त्रुटि के साथ निरस्त करें, यदि बहुत अधिक प्रविष्टियाँ विकृत की गई हैं।
-कहने का तात्पर्य यह है कि प्रश्न का उत्तर केवल कार्यक्रम के व्यापक लक्ष्यों के संदर्भ में दिया जा सकता है, जो सामान्य-उद्देश्य पुस्तकालय कार्य के लिए ज्ञात नहीं हैं। बहरहाल, एक त्रुटि संदेश के साथ बाहर निकलना संभवतः ही कभी सही उत्तर होता है। इसलिए केवल एक त्रुटि के साथ बाहर निकलने के अतिरिक्त, फ़ंक्शन जारी रखने के विभिन्न तरीकों की प्रस्तुतकश करते हुए पुनरारंभ स्थापित कर सकता है - उदाहरण के लिए, लॉग प्रविष्टि को छोड़ने के लिए, अपठनीय फ़ील्ड के लिए डिफ़ॉल्ट या शून्य मानों की आपूर्ति करने के लिए, लापता मानों के लिए उपयोगकर्ता से पूछने के लिए, या स्टैक को खोलना और एक त्रुटि संदेश के साथ प्रसंस्करण को रोकना। प्रस्तुत किए गए पुनरारंभ त्रुटि से पुनर्प्राप्त करने के लिए उपलब्ध तंत्र का गठन करते हैं; स्थिति हैंडलर द्वारा पुनरारंभ का चयन नीति की आपूर्ति करता है।
+कहने का तात्पर्य यह है कि प्रश्न का उत्तर केवल कार्यक्रम के व्यापक लक्ष्यों के संदर्भ में दिया जा सकता है, जो सामान्य-उद्देश्य पुस्तकालय कार्य के लिए ज्ञात नहीं हैं। बहरहाल, एक त्रुटि संदेश के साथ बाहर निकलना संभवतः ही कभी सही उत्तर होता है। इसलिए केवल एक त्रुटि के साथ बाहर निकलने के अतिरिक्त, फलन जारी रखने के विभिन्न विधियों की प्रस्तुतकश करते हुए पुनरारंभ स्थापित कर सकता है - उदाहरण के लिए, लॉग प्रविष्टि को छोड़ने के लिए, अपठनीय क्षेत्र के लिए डिफ़ॉल्ट या शून्य मानों की आपूर्ति करने के लिए, लापता मानों के लिए उपयोगकर्ता से पूछने के लिए, या स्टैक को खोलना और एक त्रुटि संदेश के साथ प्रसंस्करण को रोकना। प्रस्तुत किए गए पुनरारंभ त्रुटि से पुनर्प्राप्त करने के लिए उपलब्ध तंत्र का गठन करते हैं; स्थिति प्रबंधक द्वारा पुनरारंभ का चयन नीति की आपूर्ति करता है।
 === आलोचना ===
-सॉफ़्टवेयर में अपवाद प्रबंधन को अधिकांशतः ठीक से नियंत्रित नहीं किया जाता है, विशेष रूप से जब अपवादों के कई स्रोत होते हैं; जावा कोड की 5 मिलियन लाइनों के [[डेटा प्रवाह विश्लेषण]] में 1300 से अधिक अपवाद हैंडलिंग दोष पाए गए।<ref name="toplas2008">{{cite news|author1=Weimer, W|author2=Necula, G.C.|title=Exceptional Situations and Program Reliability|journal=ACM Transactions on Programming Languages and Systems |volume=30 |issue=2|url=http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|year=2008|url-status=live|archive-url=https://web.archive.org/web/20150923211739/http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|archive-date=2015-09-23}}</ref>
+सॉफ़्टवेयर में अपवाद प्रबंधन को अधिकांशतः ठीक से नियंत्रित नहीं किया जाता है, विशेष रूप से जब अपवादों के कई स्रोत होते हैं; जावा कोड की 5 मिलियन लाइनों के [[डेटा प्रवाह विश्लेषण]] में 1300 से अधिक अपवाद प्रबंधन दोष पाए गए थे।<ref name="toplas2008">{{cite news|author1=Weimer, W|author2=Necula, G.C.|title=Exceptional Situations and Program Reliability|journal=ACM Transactions on Programming Languages and Systems |volume=30 |issue=2|url=http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|year=2008|url-status=live|archive-url=https://web.archive.org/web/20150923211739/http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf|archive-date=2015-09-23}}</ref>
-दूसरों (1999-2004) के कई पूर्व अध्ययनों और अपने स्वयं के परिणामों का हवाला देते हुए, वीमर और नेकुला ने लिखा कि अपवादों के साथ एक महत्वपूर्ण समस्या यह है कि वे छिपे हुए नियंत्रण-प्रवाह पथ बनाते हैं जो प्रोग्रामर के लिए तर्क करना कठिनाई होता है।<ref name="toplas2008"/>{{rp|8:27}} जबकि ट्राई-कैच-फाइनली वैचारिक रूप से सरल है, भाषा विनिर्देश [गोस्लिंग एट अल। 1996] और इसके आधिकारिक अंग्रेजी विवरण में नेस्टेड "यदि" के चार स्तरों की आवश्यकता है। संक्षेप में, इसमें बड़ी संख्या में [[कोने के मामले]] होते हैं जिन्हें प्रोग्रामर अधिकांशतः अनदेखा कर देते हैं।<ref name="toplas2008"/>{{rp|8:13–8:14}}
-अपवाद, असंरचित प्रवाह के रूप में, [[संसाधन रिसाव]] के कठिन परिस्थिति को बढ़ाते हैं (जैसे कि एक [[म्युटेक्स]] द्वारा लॉक किए गए अनुभाग से बचना, या अस्थायी रूप से फ़ाइल को खुला रखना) या असंगत स्थिति। अपवादों की उपस्थिति में [[संसाधन प्रबंधन (कंप्यूटिंग)]] के लिए विभिन्न विधि हैं, सामान्यतः [[निपटान पैटर्न]] को किसी प्रकार की सुरक्षा (जैसे ए <code>finally</code> खंड), जो स्वचालित रूप से संसाधन को रिलीज़ करता है जब नियंत्रण कोड के एक भाग से बाहर निकलता है।
+दूसरों (1999-2004) के कई पूर्व अध्ययनों और अपने स्वयं के परिणामों का हवाला देते हुए, वीमर और नेकुला ने लिखा कि अपवादों के साथ एक महत्वपूर्ण समस्या यह है कि वे छिपे हुए नियंत्रण-प्रवाह पथ बनाते हैं जो प्रोग्रामर के लिए तर्क करने में कठिनाई होती है।<ref name="toplas2008" />{{rp|8:27}} जबकि ट्राई-कैच आखिरकार अवधारणात्मक रूप से सरल है, भाषा विनिर्देश [गोस्लिंग एट अल। 1996] और इसके आधिकारिक अंग्रेजी विवरण में नेस्टेड "यदि" के चार स्तरों की आवश्यकता है। संक्षेप में, इसमें बड़ी संख्या में [[कोने के मामले|कोने के स्थितिया]] होती हैं जिन्हें प्रोग्रामर अधिकांशतः अनदेखा कर देते हैं।<ref name="toplas2008" />{{rp|8:13–8:14}}
-में [[टोनी होरे]] ने एडा (प्रोग्रामिंग लैंग्वेज) को सुविधाओं और नोटेशनल कन्वेंशनों की अधिकता के रूप में वर्णित किया, उनमें से कई अनावश्यक और उनमें से कुछ, जैसे अपवाद हैंडलिंग, यहां तक कि खतरनाक भी। [...] इस भाषा को इसकी वर्तमान स्थिति में उन अनुप्रयोगों में उपयोग करने की अनुमति न दें जहाँ विश्वसनीयता महत्वपूर्ण है [...]। प्रोग्रामिंग लैंग्वेज की त्रुटि के परिणामस्वरूप भटकने वाला अगला रॉकेट शुक्र की हानिरहित यात्रा पर एक खोजपूर्ण अंतरिक्ष रॉकेट नहीं हो सकता है: यह हमारे अपने शहरों में से एक पर विस्फोट करने वाला परमाणु वारहेड हो सकता है।<ref>C.A.R. Hoare. "The Emperor's Old Clothes". 1980 Turing Award Lecture</ref>
+अपवाद, असंरचित प्रवाह के रूप में, [[संसाधन रिसाव]] के कठिन परिस्थिति को बढ़ाते हैं (जैसे कि एक [[म्युटेक्स]] द्वारा बंद किए गए अनुभाग से बचना, या अस्थायी रूप से फ़ाइल को खुला रखना) या असंगत स्थिति। अपवादों की उपस्थिति में [[संसाधन प्रबंधन (कंप्यूटिंग)]] के लिए विभिन्न विधि हैं, सामान्यतः [[निपटान पैटर्न|डिस्पोजल पैटर्न]] को किसी प्रकार की सुरक्षा (जैसे ए <code>finally</code> खंड) के साथ जोड़ते हैं, जो स्वचालित रूप से संसाधन को जारी करता है जब नियंत्रण कोड के एक भाग से बाहर निकलता है।
-द गो (प्रोग्रामिंग लैंग्वेज)  या Omissions डेवलपर्स का मानना है कि ट्राइ-कैच-फाइनली मुहावरा नियंत्रण प्रवाह को बाधित करता है,<ref>{{cite web |url=https://golang.org/doc/faq#exceptions |title=Frequently Asked Questions |access-date=2017-04-27 |quote=We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional. |url-status=live |archive-url=https://web.archive.org/web/20170503205801/https://golang.org/doc/faq#exceptions |archive-date=2017-05-03 }}</ref> और अपवाद की तरह प्रस्तुत किया {{code|lang=go|panic}}/{{code|lang=go|recover}} तंत्र।<ref>[https://code.google.com/p/go-wiki/wiki/PanicAndRecover Panic And Recover] {{webarchive|url=https://web.archive.org/web/20131024144034/https://code.google.com/p/go-wiki/wiki/PanicAndRecover |date=2013-10-24 }}, Go wiki</ref> {{code|lang=go|recover()}} से मतभेद होना {{code|catch}} इसमें इसे केवल a के अंदर से ही बुलाया जा सकता है {{code|lang=go|defer}} एक फ़ंक्शन में कोड ब्लॉक, इसलिए हैंडलर केवल क्लीन-अप कर सकता है और फ़ंक्शन के रिटर्न वैल्यू को बदल सकता है, और फ़ंक्शन के अंदर एक इच्छानुसार बिंदु पर नियंत्रण वापस नहीं कर सकता।<ref>{{cite web |last1=Bendersky |first1=Eli |title=On the uses and misuses of panics in Go |url=https://eli.thegreenplace.net/2018/on-the-uses-and-misuses-of-panics-in-go/ |website=Eli Bendersky's website |access-date=5 January 2022 |date=8 August 2018|quote=The specific limitation is that recover can only be called in a defer code block, which cannot return control to an arbitrary point, but can only do clean-ups and tweak the function's return values. }}</ref>  {{code|lang=go|defer}}<nowiki> }} खुद को ब्लॉक करता है a के समान कार्य करता है </nowiki>{{code|finally}} खंड।
+में [[टोनी होरे]] ने एडा (प्रोग्रामिंग भाषा) वर्णन इस प्रकार किया था "सुविधाओं और सांकेतिक सम्मेलन उनमें से कई अनावश्यक हैं, और उनमें से कुछ, जैसे अपवाद प्रबंधन, यहां तक कि खतरनाक भी है । [...] इस भाषा को इसकी वर्तमान स्थिति में उन अनुप्रयोगों में उपयोग करने की अनुमति न दें जहाँ विश्वसनीयता महत्वपूर्ण है [...]। प्रोग्रामिंग भाषा की त्रुटि के परिणामस्वरूप भटकने वाला अगला रॉकेट शुक्र की हानिरहित यात्रा पर एक खोजपूर्ण अंतरिक्ष रॉकेट नहीं हो सकता है: यह हमारे अपने शहरों में से एक पर विस्फोट करने वाला परमाणु बम हो सकता है।<ref>C.A.R. Hoare. "The Emperor's Old Clothes". 1980 Turing Award Lecture</ref>
+द गो (प्रोग्रामिंग भाषा ) डेवलपर्स का मानना है कि  ट्राई-कैच-अंतिम मुहावरा नियंत्रण प्रवाह को अवरोधित करता है,<ref>{{cite web |url=https://golang.org/doc/faq#exceptions |title=Frequently Asked Questions |access-date=2017-04-27 |quote=We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional. |url-status=live |archive-url=https://web.archive.org/web/20170503205801/https://golang.org/doc/faq#exceptions |archive-date=2017-05-03 }}</ref> और अपवाद जैसे {{code|lang=go|panic}}/{{code|lang=go|recover}} तंत्र कि प्रारंभ कि ।<ref>[https://code.google.com/p/go-wiki/wiki/PanicAndRecover Panic And Recover] {{webarchive|url=https://web.archive.org/web/20131024144034/https://code.google.com/p/go-wiki/wiki/PanicAndRecover |date=2013-10-24 }}, Go wiki</ref> {{code|lang=go|recover()}} {{code|catch}} से अलग है इसे केवल फलन में {{code|lang=go|defer}} कोड ब्लॉक के भीतर से ही बुलाया जा सकता है, इसलिए प्रबंधक केवल क्लीन-अप कर सकता है और फलन के वापसी मान को बदल सकता है, और फलन के अंदर एक इच्छानुसार बिंदु पर नियंत्रण वापस नहीं कर सकता।<ref>{{cite web |last1=Bendersky |first1=Eli |title=On the uses and misuses of panics in Go |url=https://eli.thegreenplace.net/2018/on-the-uses-and-misuses-of-panics-in-go/ |website=Eli Bendersky's website |access-date=5 January 2022 |date=8 August 2018|quote=The specific limitation is that recover can only be called in a defer code block, which cannot return control to an arbitrary point, but can only do clean-ups and tweak the function's return values. }}</ref> {{code|lang=go|defer}}<nowiki> }}ब्लॉक करता स्वयं </nowiki>{{code|finally}} खंड के समान कार्य करता है।।
 == यूआई पदानुक्रमों में अपवाद प्रबंधन ==
-[[प्रतिक्रिया (जावास्क्रिप्ट पुस्तकालय)]] और Vue.js जैसे फ्रंट-एंड वेब फ्रेमवर्क ने एरर हैंडलिंग मैकेनिज्म प्रस्तुत किया है, जहां एरर यूआई कंपोनेंट पदानुक्रम को एक तरह से फैलाते हैं, जो कोड को निष्पादित करने में कॉल स्टैक को कैसे फैलाते हैं, इसके अनुरूप है।<ref>{{Cite web|url=https://reactjs.org/docs/error-boundaries.html|title=Error Boundaries|website=React|access-date=2018-12-10}}</ref><ref>{{Cite web|url=https://vuejs.org/v2/api/#errorCaptured|title=Vue.js API|website=Vue.js|access-date=2018-12-10}}</ref> यहां एरर बाउंड्री मैकेनिज्म ठेठ ट्राई-कैच मैकेनिज्म के एनालॉग के रूप में काम करता है। इस प्रकार एक घटक यह सुनिश्चित कर सकता है कि उसके बाल घटकों से त्रुटियां पकड़ी और संभाली जाती हैं, और मूल घटकों तक प्रचारित नहीं की जाती हैं।
+फ्रंट-एंड वेब फ्रेमवर्क जैसे [[प्रतिक्रिया (जावास्क्रिप्ट पुस्तकालय)|प्रतिक्रिया]] वीयूई ने त्रुटि प्रबंधन मैकेनिज्म प्रस्तुत किया गया है, जहां त्रुटि यूआई कंपोनेंट पदानुक्रम को एक तरह से फैलाते हैं, जो कोड को निष्पादित करने में कॉल अंबार को कैसे फैलाते हैं, इसके अनुरूप है।<ref>{{Cite web|url=https://reactjs.org/docs/error-boundaries.html|title=Error Boundaries|website=React|access-date=2018-12-10}}</ref><ref>{{Cite web|url=https://vuejs.org/v2/api/#errorCaptured|title=Vue.js API|website=Vue.js|access-date=2018-12-10}}</ref> यहां त्रुटि सीमा तंत्र प्ररूपी  ट्राई-कैच तंत्र के एनालॉग के रूप में काम करता है। इस प्रकार एक घटक यह सुनिश्चित कर सकता है कि उसके बाल घटकों से त्रुटियां पकड़ी और संभाली जाती हैं, और मूल घटकों तक प्रचारित नहीं की जाती हैं।
-उदाहरण के लिए, Vue में, एक घटक प्रयुक्त करके त्रुटियों को पकड़ लेगा <code>errorCaptured</code><syntaxhighlight>
+उदाहरण के लिए, वीयूई में, एक घटक प्रयुक्त करके त्रुटियों को पकड़ लेता है | <code>errorCaptured</code><syntaxhighlight>
 Vue.component('parent', {
      template: '<div><slot></slot></div>',
@@ Line 280: / Line 283: @@
 == यह भी देखें ==
-* स्वचालित अपवाद हैंडलिंग
+* स्वचालित अपवाद प्रबंधन
 * [[अपवाद सुरक्षा]]
 * जारी
@@ Line 290: / Line 293: @@
 ==टिप्पणियाँ==
 {{reflist|group=note}}
-{{notelist}}
@@ Line 320: / Line 322: @@
 * Article "[http://oreillynet.com/pub/a/network/2003/05/05/cpluspocketref.html Programming with Exceptions in C++]" by Kyle Loudon
 * Article "[http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Unchecked Exceptions - The Controversy]"
-* Conference slides [http://www.eecs.berkeley.edu/~wkahan/Boulder.pdf Floating-Point Exception-Handling policies (pdf p. 46) ] by William Kahan
+* Conference slides [http://www.eecs.berkeley.edu/~wkahan/Boulder.pdf Floating-Point Exception-Handling policies (pdf p. 46)] by William Kahan
 * [http://c2.com/cgi/wiki?CategoryException Descriptions from Portland Pattern Repository]
 * [https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions Does Java Need Checked Exceptions?]
-{{Data types}}
-{{Authority control}}
 {{DEFAULTSORT:Exception Handling}}
-<!--Categories-->[[Category: बहाव को काबू करें]] [[Category: सॉफ्टवेयर विसंगतियाँ]]
+[[Category: बहाव को काबू करें]] [[Category: सॉफ्टवेयर विसंगतियाँ]]
@@ Line 334: / Line 332: @@
 [[Category: Machine Translated Page]]
 [[Category:Created On 17/02/2023]]
+[[Category:Vigyan Ready]]

Anonymous

Search

एक्सेप्शन हेंडलिंग: Difference between revisions

Latest revision as of 06:39, 19 October 2023

परिभाषा

इतिहास

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

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

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

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

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

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

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

अनकहा अपवाद

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

समान तंत्र

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

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

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

निरंतर अपवाद

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

आलोचना

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

यह भी देखें

टिप्पणियाँ

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories