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

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

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

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

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

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

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

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

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

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

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

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

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

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

रेफरी नाम = कंघी बनानेवाले की रेती>

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

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

अपवाद क्या है, इस बारे में उनकी धारणा में प्रोग्रामिंग भाषाएं अधिक हद तक भिन्न हैं। समकालीन भाषाओं को मोटे तौर पर दो समूहों में विभाजित किया जा सकता है:
 * भाषाएँ जहाँ अपवादों को प्रवाह नियंत्रण संरचनाओं के रूप में उपयोग करने के लिए डिज़ाइन किया गया है: Ada, Modula-3, ML, OCaml, PL/I, Python, और Ruby इस श्रेणी में आते हैं। उदाहरण के लिए, Iterator या Python|Python के पुनरावर्तक StopIteration अपवादों को यह संकेत देने के लिए फेंकते हैं कि पुनरावर्तक द्वारा कोई और आइटम नहीं बनाया गया है।
 * भाषाएँ जहाँ अपवादों का उपयोग केवल असामान्य, अप्रत्याशित, गलत स्थितियों को संभालने के लिए किया जाता है: C++, जावा, सी या, कॉमन लिस्प, एफिल और मोडुला -2।

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण के लिए, Vue में, एक घटक प्रयुक्त करके त्रुटियों को पकड़ लेगा  मार्कअप में इस तरह उपयोग किए जाने पर: चाइल्ड घटक द्वारा उत्पन्न त्रुटि को पैरेंट घटक द्वारा पकड़ा और नियंत्रित किया जाता है।

यह भी देखें

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

बाहरी संबंध

 * 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?