अपवादों को कोड लिखना वास्तव में आसान होता है, जहां एक अपवाद को फेंक दिया जाता है, जो आक्रमणकारियों को तोड़ देगा और वस्तुओं को असंगत स्थिति में छोड़ देगा। वे अनिवार्य रूप से आपको यह याद रखने के लिए मजबूर करते हैं कि आपके द्वारा दिया गया प्रत्येक कथन संभावित रूप से फेंक सकता है, और सही ढंग से संभाल सकता है। ऐसा करना मुश्किल और जवाबी हो सकता है।
एक साधारण उदाहरण के रूप में इस तरह से कुछ पर विचार करें:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
FrobManagerवसीयत deleteको मानते हुए FrobObject, यह ठीक लगता है, है ना? या हो सकता है नहीं ... तो कल्पना कीजिए कि यदि या तो FrobManager::HandleFrob()या operator newएक अपवाद फेंकता है। इस उदाहरण में, वेतन वृद्धि m_NumberOfFrobsवापस नहीं मिलती है। इस प्रकार, इस उदाहरण का उपयोग Frobberकरने वाले के पास संभवतः दूषित वस्तु होने वाली है।
यह उदाहरण बेवकूफी भरा लग सकता है (ठीक है, मुझे एक निर्माण के लिए खुद को थोड़ा लंबा करना पड़ा), लेकिन, टेकअवे यह है कि अगर कोई प्रोग्रामर लगातार अपवादों के बारे में नहीं सोच रहा है, और यह सुनिश्चित कर रहा है कि राज्य के प्रत्येक क्रमांकन को लुढ़का हुआ है। वापस जब भी फेंकता है, आप इस तरह से मुसीबत में पड़ जाते हैं।
एक उदाहरण के रूप में, आप इसके बारे में सोच सकते हैं जैसे आप म्यूटेक्स के बारे में सोचते हैं। एक महत्वपूर्ण खंड के अंदर, आप यह सुनिश्चित करने के लिए कई कथनों पर भरोसा करते हैं कि डेटा संरचनाएँ दूषित नहीं हैं और अन्य सूत्र आपके मध्यवर्ती मूल्यों को नहीं देख सकते हैं। यदि उन बयानों में से कोई भी बस अनियमित रूप से नहीं चलता है, तो आप दर्द की दुनिया में समाप्त हो जाते हैं। अब ताले और संगति को हटा दें, और उस तरह से प्रत्येक विधि के बारे में सोचें। प्रत्येक विधि को वस्तु स्थिति पर क्रमपरिवर्तन के लेन-देन के रूप में सोचें, यदि आप करेंगे। आपके विधि कॉल के प्रारंभ में, ऑब्जेक्ट को साफ स्थिति होना चाहिए, और अंत में एक साफ राज्य भी होना चाहिए। बीच में, चर के fooसाथ असंगत हो सकता हैbar, लेकिन आपका कोड अंततः उसे ठीक कर देगा। अपवादों का क्या मतलब है कि आपका कोई भी कथन किसी भी समय आपको बाधित कर सकता है। यह प्रत्येक अधिकार विधि में आप पर है कि यह सही हो जाए और जब ऐसा होता है तो वापस रोल करें, या अपने संचालन का आदेश दें ताकि फेंकता वस्तु स्थिति को प्रभावित न करे। यदि आपको यह गलत लगता है (और इस तरह की गलती करना आसान है), तो कॉलर आपके मध्यवर्ती मूल्यों को देखकर समाप्त हो जाता है।
RAII जैसी विधियाँ, जिन्हें C ++ प्रोग्रामर इस समस्या के अंतिम समाधान के रूप में उल्लेख करना पसंद करते हैं, इस से बचाव के लिए एक लंबा रास्ता तय करते हैं। लेकिन वे चांदी की गोली नहीं हैं। यह सुनिश्चित करेगा कि आप संसाधनों को एक थ्रो पर जारी करेंगे, लेकिन आपको वस्तु स्थिति के भ्रष्टाचार और मध्यवर्ती मूल्यों को देखने वाले कॉलर्स के बारे में सोचने से मुक्त नहीं करते हैं। इसलिए, बहुत से लोगों के लिए, कोडिंग शैली के अनुसार, कोई अपवाद नहीं है , यह कहना आसान है । यदि आप अपने द्वारा लिखे गए कोड को प्रतिबंधित करते हैं, तो इन बगों को लागू करना कठिन है। यदि आप नहीं करते हैं, तो गलती करना काफी आसान है।
C ++ में अपवाद सुरक्षित कोडिंग के बारे में पूरी किताबें लिखी गई हैं। बहुत सारे विशेषज्ञों ने इसे गलत माना है। यदि यह वास्तव में जटिल है और इसमें बहुत सारी बारीकियाँ हैं, तो शायद यह एक अच्छा संकेत है कि आपको उस सुविधा को अनदेखा करने की आवश्यकता है। :-)