अपवाद संचालन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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