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

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

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

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

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

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

<वाक्यविन्यास प्रकाश लैंग = सीशार्प> कोशिश { लाइन = कंसोल.रीडलाइन ;

अगर (रेखा। लंबाई == 0) { नया EmptyLineException फेंकें (कंसोल से पढ़ी गई लाइन खाली थी!); }

कंसोल.प्रिंटलाइन (हैलो %s! % लाइन); } पकड़ (खाली लाइन अपवाद ई) { कंसोल.प्रिंटलाइन (हैलो!); } पकड़ (अपवाद ई) { कंसोल.प्रिंटलाइन (त्रुटि: + ई.संदेश ); } अन्य { कंसोल.प्रिंटलाइन (कार्यक्रम सफलतापूर्वक चला।); } आखिरकार { कंसोल.प्रिंटलाइन (कार्यक्रम अब समाप्त हो रहा है।); } 

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

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

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


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

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


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

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

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

<वाक्यविन्यास लैंग = एफिल> भेजें (एम: संदेश) है - m को फास्ट लिंक से भेजें, हो सके तो स्लो लिंक से। स्थानीय try_fast, try_slow: बूलियन करना अगर try_fast तब try_slow := सच Send_slow (एम) अन्य try_fast := सच Send_fast (एम) अंत बचाव अगर try_slow नहीं किया तो पुन: प्रयास अंत अंत 

शुरुआत में बूलियन स्थानीय चरों को 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 में, एक घटक लागू करके त्रुटियों को पकड़ लेगा <वाक्यविन्यास लैंग = जावास्क्रिप्ट> Vue.component ('पैरेंट', {   साँचा: '  ',    त्रुटि कैद: (त्रुटि, वीएम, जानकारी) => चेतावनी ('एक त्रुटि हुई'); }) Vue.component ('चाइल्ड', {   टेम्पलेट: '  ' }) मार्कअप में इस तरह उपयोग किए जाने पर: चाइल्ड घटक द्वारा उत्पन्न त्रुटि को पैरेंट घटक द्वारा पकड़ा और नियंत्रित किया जाता है।

यह भी देखें

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

बाहरी संबंध

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