موضوع مقاله: ایمنی در استثنا | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # ایمنی در استثنا | مقدمه: ایمنی در برابر استثنا به حالتی گفته می‌شود که در آن کد در صورت بروز استثنا همچنان به‌درستی عمل می‌کند. | ## بخش 1: ایمنی در استثنا | برای کمک به تضمین این نوع ایمنی، توسعه‌دهندگان کتابخانه‌ی استاندارد ++C مجموعه‌ای از سطوح ایمنی در برابر استثنا را تعریف کرده‌اند؛ این سطوح در واقع تضمین‌هایی قراردادی هستند که رفتار عملیات یک ساختار داده را در مواجهه با استثنا مشخص می‌کنند. این تضمین‌ها به توسعه‌دهندگان کتابخانه‌ها و کاربران آن‌ها کمک می‌کند تا در تحلیل درستی مدیریت استثناها، بهتر عمل کنند. این سطوح ایمنی نه‌تنها در زبان ++C بلکه در سایر زبان‌ها و سازوکارهای مدیریت خطا نیز قابل اعمال هستند.</blockquote> تاریخچه همان‌طور که دیوید آبراهامز می‌نویسد، «پیش از آن‌که زبان ++C استثناها را معرفی کند، هیچ‌کس از 'ایمنی در برابر خطا' سخنی به میان نیاورده بود.» این اصطلاح نخستین‌بار در سال ۱۹۹۴ در قالب موضوعی در اسناد گروه استانداردسازی زبان ++C (JTC1/SC22/WG21) ظاهر شد. ایمنی در برابر استثنا برای کتابخانه‌ی استاندارد ++C نخستین‌بار توسط آبراهامز و در پیاده‌سازی STLport به‌صورت رسمی تعریف شد و تفاوت میان "ایمنی پایه" و "ایمنی قوی" را بنیان نهاد. این تقسیم‌بندی بعدها در قالب پیشنهادی دیگر گسترش یافت و تضمین‌های سه‌گانه‌ی «پایه»، «قوی» و «بدون پرتاب» (nothrow) شکل گرفتند. | ## بخش 2: ایمنی در استثنا | این روندِ «بالا رفتن» ممکن است با مختل‌کردن وضعیت‌های درونی یک ساختار داده‌ی قابل تغییر (mutable)، به بروز اشکال در ایمنی استثنا منجر شود. این فرآیند به‌صورت زیر رخ می‌دهد: در یکی از مراحل یک عملیات روی ساختار داده، تغییری اعمال می‌شود که یک وضعیت پایدار (invariant) را نقض می‌کند؛ استثنایی پرتاب می‌شود و اجرای کد به‌جای ادامه، به سطح بالاتری منتقل می‌شود و در نتیجه، کدهای باقی‌مانده‌ای که باید وضعیت پایدار را بازگردانند اجرا نمی‌شوند؛ استثنا یا گرفته و مدیریت می‌شود، یا اجرای کد وارد یک بلوک finally می‌شود؛ ساختار داده‌ای که وضعیت آن اکنون ناپایدار است، توسط کدی که انتظار دارد وضعیت پایدار باشد، مورد استفاده قرار می‌گیرد، و در نتیجه، اشکال (باگ) رخ می‌دهد. کدی که چنین رفتاری از خود نشان می‌دهد، به عنوان «فاقد ایمنی در برابر استثنا» شناخته می‌شود. اگر استثنایی رخ دهد، به‌طور داخلی مدیریت شده و در سطح کاربر (client) مشاهده نمی‌شود. به بیان دیگر، داده‌های ذخیره‌شده معتبر خواهند بود، هرچند ممکن است با مقادیر اولیه تفاوت داشته باشند. | ## بخش 3: ایمنی در استثنا | دستیابی به سطوح بالاتر از ایمنی ممکن است دشوار بوده و به‌دلیل نیاز به کپی‌برداری‌های اضافی، هزینه‌ی عملکردی به‌همراه داشته باشد. یکی از سازوکارهای کلیدی در تأمین ایمنی استثنا، استفاده از بلوک finally (یا سازوکاری مشابه) است که تضمین می‌کند بخشی از کد همواره، حتی در صورت وقوع استثنا، اجرا خواهد شد. زمانی که عنصری مانند x به برداری به نام v افزوده می‌شود، بردار باید واقعاً x را به فهرست داخلی خود اضافه کند و همچنین شمارنده‌ای را به‌روزرسانی کند که نشان می‌دهد چند عنصر در v وجود دارد. سطوح مختلف ایمنی در برابر استثنا در این مثال به‌صورت زیر پیاده‌سازی می‌شوند: تضمین عدم پرتاب (No-throw guarantee): این سطح با اطمینان از این‌که تخصیص حافظه هرگز با شکست مواجه نمی‌شود، یا با تعریف رفتاری مشخص در صورت شکست تخصیص (مثلاً بازگرداندن یک مقدار بولی که نشان می‌دهد آیا درج موفق بوده یا نه) قابل پیاده‌سازی است. در نتیجه، یا x با موفقیت به v افزوده می‌شود، یا اگر مشکلی رخ دهد، v بدون تغییر باقی می‌ماند. | ## جمع‌بندی | برای مثال، اگر خطایی رخ دهد، تابع درج ممکن است کل محتوای v را آزاد کرده و شمارنده را به صفر بازنشانی کند.