कोड के एक टुकड़े को अपवाद-सुरक्षित कहा जाता है, यदि कोड के अंदर रन-टाईम असफलता समृति रहस्योद्घाटन, जमा आकड़ा अस्पष्टता, या अमान्य परिणाम जैसे खराब प्रभाव पैदा नहीं करती. अपवाद-सुरक्षा कोड को कोड मे रखे गए इनवैरिअंट्स को संतुष्ट करना चाहिए, भले ही अपवाद घटित हों. अपवाद सुरक्षा के कई स्तर हैं:

उदाहरण के लिए, C++'s codice_1या जावा codice_2जैसे एक समार्ट वेक्टर टाईप पर विचार करें। जब एक आइटम "x" को वेक्टर "v" से जोड़ा जाता है तो वेक्टर को चाहिए कि वह" x " को वस्तु के इन्टरनेट सूची से जोड़े और उस गिनती क्षेत्र को अपडेट करे जो बताती है कि "v" में कितने पदार्थ हैं। नयी स्मृति को आबंटित करने की भी जरूरत पड़ सकती है यदि मौजूद क्षमता पर्याप्त बड़ी नहीं है। यह स्मृति आवंटन विफल हो सकता है और एक अपवाद को पैदा करता है। इस वजह से, एक वेक्टर जो विफल पारदर्शिता प्रदान करता है उसे लिखना बहुत मुश्किल या असंभव होता है। हालांकि, वेक्टर काफी हद तक एक मजबूत अपवाद गारंटी आसानी से दे सकता है, इस मामले में," v" का" x" में प्रवेश करना या तो सफल हो सकता है या" v" अपरिवर्तित रहता है। अगर वेक्टर केवल आधारभूत अपवाद सुरक्षा गारंटी प्रदान करता है, अगर अंतर्वेश असफल होता है," v" "x" को धारित कर भी सकता है और नहीं भी, लेकिन यह कम से कम सामान अवस्था में रहेगा. हालांकि, अगर वेक्टर केवल न्यूनतम गारंटी देता है, यह संभव है कि वेक्टर अमान्य हो जाये. उदाहरण के लिए, शायद "v" का क्षेत्र आकार बढ़ाया गया था लेकिन वास्तव में अवस्था को असंगत करते हुए" x" को प्रवेश नहीं कराया गया था। बेशक, बिना गारंटी के, प्रोग्राम दुर्घटनाग्रस्त हो सकता है; शायद वेक्टर के विस्तार की जरूरत थी लेकिन वह स्मृति को आबंटित नहीं कर सका और अमान्य पते पर स्मृति का स्पर्श करते हुए आगे के क्षेत्र की अंधाधुंध खुदाई कर दी मानो आबंटन सफल हो गया हो।

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

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