उनके बारे में अपवाद और मिथक

यह पहली बार नहीं है जब मैंने अपवादों को उठाने के लिए अनम्य रवैया का सामना किया है। इसे उठाना है, क्योंकि बहुमत के अवरोधन के लिए राय समान है: केवल तब अवरोधक जब आप वास्तव में संभाल सकते हैं। राइजिंग को कुछ असाधारण माना जाता है, सामान्य से बाहर। जब वे एक फेंक देखते हैं, तो वे कहानियों का एक गुच्छा बताने लगते हैं कि कैसे ...

याद रखें कि भय से कैसे निपटें? आप एक मिनट को पकड़ते हैं, जिसके दौरान आप अपनी सभी भावनाओं को मुफ्त में देते हैं। फिर आप अपने आप को "पर्याप्त" कहते हैं और समस्याओं में सिर झुकाते हैं। एक मिनट बीत गया।

शुरू करने के लिए, आइए जानें कि यह किस प्रकार का जानवर है। मैं निम्नलिखित गुणों को उजागर करता हूं:

• आक्रामक को अनदेखा करना असंभव;
• एक स्थान पर कई हैंडलर;
• किसी भी नेस्टेड कॉल के माध्यम से रिसना;
• स्वतंत्र डेटा संरचना प्रोसेसर को पारित कर दिया - याद रखें, कॉम फ़ंक्शन और अन्य बकवास कॉल करने के लिए मैक्रोज़, जो अपवाद तंत्र की अनुपस्थिति (या उपयोग करने की अनिच्छा) के लिए अपने अस्तित्व का श्रेय देता है

और वह सब है। सभी प्रकार के प्रदर्शन के नुकसान, नियंत्रण की जटिलता संदर्भ-संवेदनशील (और अक्सर सिर्फ दूर की कौड़ी होती है) और प्रत्येक मामले में प्रमाण की आवश्यकता होती है।

उदाहरण के लिए: फ़ाइल खोजें।

int FindSymbol(TextReader reader, char symb)
{
char cur;
int pos;
while (cur = (char)reader.Read())
{
if (cur == 'a')
throw new FormatException();
pos ++;
if (cur == symb)
return pos;
}
throw new MyException(); }
}


एक समारोह से बाहर निकलने के लिए निम्नलिखित विकल्प परिभाषित हैं:

• आवश्यक डेटा मिला (रिटर्न पॉज़)
• फ़ाइल सही प्रारूप में नहीं है (फेंकें)
• फ़ाइल समाप्त हो गई है (पाठक एक अपवाद उठाता है)

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

ग्राहक को अब एक जटिल परिणाम का विश्लेषण करने की आवश्यकता नहीं है, उसने पाठ खोजने के लिए कहा - वह पाया गया; यदि नहीं, तो वह इसके बारे में भी नहीं जानता।

एक अन्य उदाहरण: उपयोगकर्ता का संसाधन रद्द करना बटन पर क्लिक करता है। फिर, आप इस विषय पर लंबे समय तक चर्चा कर सकते हैं - यह तंत्र मूल रूप से क्यों बनाया गया था?

लेकिन अगर यह मौजूद है और "रद्द" तर्क के लिए उपयुक्त है, तो इसका उपयोग न करना मूर्खता है।
जब मुझे दो बार बिना सोचे घर पर मिलों को गोंद करने की जरूरत पड़ी, तो मैंने लोड के रूप में M.Pc-Donald की पुस्तक "Wpf ..." का उपयोग किया। तो अन्य मामलों में मुझे क्यों करना चाहिए?

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

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

अपवादों को बढ़ाने के लिए इस रवैये के विरोधियों के बीच मुख्य तर्क एक प्रदर्शन में कमी है। इसके साथ बहस करना मूर्खतापूर्ण है - सशर्त बयान कई गुना अधिक कुशल है। लेकिन एक "लेकिन" है: समस्या को वास्तविक डेटा पर साबित किया जाना चाहिए। मान लें कि कोड का एक टुकड़ा वास्तव में महत्वपूर्ण है। अरे डरपोक! - अब आपको रिफैक्टरिंग पर कुछ घंटे बिताने होंगे। दिन नहीं, अर्थात् घंटे। याद रखें कि फाउलर ने डिजाइन के बारे में अपने दृष्टिकोण के बारे में बताया था: “... मैं यह निर्धारित करने की कोशिश कर रहा हूं कि एक डिजाइन से दूसरे डिजाइन को रिफलेक्टर करना कितना मुश्किल होगा। यदि कठिनाइयाँ दिखाई नहीं दे रही हैं, तो मैं पसंद के बारे में बहुत अधिक नहीं सोच रहा हूँ, सरलतम पर ध्यान केन्द्रित करें। ”

यदि हम मान लेते हैं कि हम इस साहसिक विचार को स्वीकार करते हैं, तो यह रिफ्लेक्टरिंग ऑर्डर पर निर्णय लेने के लिए बना रहता है:

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

इस तरह यह कोड में दिखेगा।

• स्रोत कोड:
  class SrcClass
{
public void Exec()
{
throw new MyException();
}
}
• तीसरे चरण के बाद:
  class SrcClass
{
public void Exec()
{
if (!TryExec())
throw new MyException();
}
public bool TryExec()
{
return false;
}
}
• नौवें चरण के बाद:
  class SrcClass
{
public void Exec()
{
if (!TryExec())
throw new MyException();
}
public bool TryExec()
{
return false;
}
}

static class SrcClassHelper
{
public static bool TryExecHelp(this SrcClass src)
{
try
{
src.Exec();
return true;
}
catch (MyException)
{
return false;
}
}
public static void Exec(this SrcClass src)
{
if (!src.TryExec())
throw new MyException();
}
}
• पूरा होने पर:
  class SrcClass
{
public bool TryExec()
{
return false;
}
}

static class SrcClassHelper
{
public static void Exec(this SrcClass src)
{
if (!src.TryExec())
throw new MyException();
}
}

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