एक असाधारण स्थिति की वास्तुकला: 4 का पीटी 2

मुझे लगता है कि इस विषय में सबसे महत्वपूर्ण मुद्दों में से एक आपके आवेदन में एक अपवाद हैंडलिंग वास्तुकला का निर्माण कर रहा है। यह कई कारणों से दिलचस्प है। और मुख्य कारण, मुझे लगता है, एक स्पष्ट सादगी है, जिसे आप हमेशा नहीं जानते कि क्या करना है। सभी बुनियादी निर्माण जैसे IEnumerable , IDisposable , IObservable , आदि। इस संपत्ति है और हर जगह इसका इस्तेमाल करते हैं। एक ओर, उनकी सादगी विभिन्न स्थितियों में इन निर्माणों का उपयोग करने का संकेत देती है। दूसरी ओर, वे जाल से भरे हुए हैं जो आप बाहर नहीं निकल सकते। यह संभव है कि आपके द्वारा कवर की गई जानकारी की मात्रा को देखकर आपको एक सवाल मिल गया हो: असाधारण स्थितियों के बारे में क्या खास है?

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

भविष्य के अपवाद को पकड़ने के लिए एक सैद्धांतिक संभावना के आधार पर।

इस विशेषता के आधार पर हम उन अपवादों को विभाजित कर सकते हैं जो निश्चित रूप से पकड़े जाएंगे और जो अत्यधिक संभावना वाले हैं उन्हें नहीं पकड़ा जाएगा। मैं अत्यधिक संभावना क्यों कहूं? क्योंकि हमेशा कोई ऐसा व्यक्ति होता है जो एक अपवाद को पकड़ने की कोशिश करेगा जबकि यह अनावश्यक है।

पहले, चलो अपवादों के पहले समूह का वर्णन करते हैं - जिन्हें पकड़ा जाना चाहिए।

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

दूसरा समूह अपवादों से संबंधित है, हालांकि यह अजीब लग सकता है, इसे पकड़ा नहीं जाना चाहिए। उनका उपयोग केवल त्रुटि लॉगिंग के लिए किया जा सकता है, लेकिन किसी स्थिति को सही करने के लिए नहीं। सबसे सरल उदाहरण है ArgumentException और NullReferenceException । वास्तव में, एक साधारण स्थिति में आपको पकड़ने की आवश्यकता नहीं है, उदाहरण के लिए, ArgumentNullException क्योंकि इस मामले में एक त्रुटि का स्रोत बिल्कुल आप है। यदि आप इस तरह के अपवाद को पकड़ते हैं, तो आप स्वीकार करते हैं कि आपने एक त्रुटि की है और एक विधि के लिए अस्वीकार्य है:

 void SomeMethod(object argument) { try { AnotherMethod(argument); } catch (ArgumentNullException exception) { // Log it } } 

इस विधि में हम ArgumentNullException को पकड़ने का प्रयास करते हैं। लेकिन मुझे लगता है कि यह अजीब है क्योंकि एक विधि के लिए सही तर्क देना पूरी तरह से हमारी चिंता है। घटना के बाद प्रतिक्रिया करना गलत होगा: ऐसी स्थिति में आप जो सबसे अच्छा काम कर सकते हैं, वह यह है कि विधि को कॉल करने से पहले अग्रिम में पास किए गए डेटा की जांच करें या ऐसे कोड का निर्माण भी करें जहां गलत पैरामीटर प्राप्त करना असंभव है।

असाधारण स्थितियों का एक और समूह घातक त्रुटियां हैं। यदि कुछ कैश दोषपूर्ण है और एक सबसिस्टम का काम वैसे भी गलत है, तो यह एक घातक त्रुटि है और स्टैक पर निकटतम कोड इसे सुनिश्चित करने के लिए नहीं पकड़ेंगे:

 T GetFromCacheOrCalculate() { try { if(_cache.TryGetValue(Key, out var result)) { return result; } else { T res = Strategy(Key); _cache[Key] = res; return res; } } cache (CacheCorruptedException exception) { RecreateCache(); return GetFromCacheOrCalculate(); } } 

CacheCorruptedException एक अपवाद का अर्थ है कि "हार्ड ड्राइव कैश असंगत है"। फिर, यदि इस तरह की त्रुटि का कारण कैश सबसिस्टम के लिए घातक है (उदाहरण के लिए कैश फ़ाइल एक्सेस अधिकार नहीं हैं), तो निम्न कोड फिर से RecreateCache पुनः निर्देश का उपयोग करके पुन: नहीं बना सकता है और इसलिए इस अपवाद को पकड़ना स्वयं एक त्रुटि है।

उस क्षेत्र के आधार पर जहां एक असाधारण स्थिति वास्तव में पकड़ी जाती है

एक और मुद्दा यह है कि क्या हमें कुछ अपवादों को पकड़ना चाहिए या उन्हें किसी ऐसे व्यक्ति के पास भेजना चाहिए जो स्थिति को बेहतर समझता है। दूसरे शब्दों में, हमें जिम्मेदारी के क्षेत्रों की स्थापना करनी चाहिए। आइए निम्नलिखित कोड की जांच करें:

 namespace JetFinance.Strategies { public class WildStrategy : StrategyBase { private Random random = new Random(); public void PlayRussianRoulette() { if(DateTime.Now.Second == (random.Next() % 60)) { throw new StrategyException(); } } } public class StrategyException : Exception { /* .. */ } } namespace JetFinance.Investments { public class WildInvestment { WildStrategy _strategy; public WildInvestment(WildStrategy strategy) { _strategy = strategy; } public void DoSomethingWild() { ?try? { _strategy.PlayRussianRoulette(); } catch(StrategyException exception) { } } } } using JetFinance.Strategies; using JetFinance.Investments; void Main() { var foo = new WildStrategy(); var boo = new WildInvestment(foo); ?try? { boo.DoSomethingWild(); } catch(StrategyException exception) { } } 

दोनों में से कौन सी रणनीति अधिक उपयुक्त है? जिम्मेदारी का क्षेत्र बहुत महत्वपूर्ण है। प्रारंभ में, ऐसा लग सकता है कि WildInvestment का कार्य और निरंतरता पूरी तरह से WildInvestment पर निर्भर करती है। इस प्रकार, यदि WildInvestment केवल इस अपवाद को अनदेखा करता है, तो यह ऊपरी स्तर पर जाएगा और हमें कुछ भी नहीं करना चाहिए। हालांकि, ध्यान दें कि वास्तुकला के संदर्भ में Main विधि एक स्तर से एक अपवाद को पकड़ती है, जबकि विधि दूसरे से कॉल करती है। उपयोग के संदर्भ में यह कैसा दिखता है? ठीक है, यह है कि यह कैसा दिखता है:

• इस अपवाद की जिम्मेदारी हमें सौंपी गई थी;
• इस वर्ग का उपयोगकर्ता यह सुनिश्चित नहीं करता है कि यह अपवाद पहले उद्देश्य के तरीकों के एक सेट के माध्यम से पारित किया गया था;
• हम नई निर्भरताएँ बनाना शुरू करते हैं जिन्हें हमने मध्यवर्ती परत कहकर छुटकारा दिलाया।

हालांकि, इस एक के परिणामस्वरूप एक और निष्कर्ष है: हमें DoSomethingWild विधि में catch का उपयोग करना चाहिए। और यह हमारे लिए थोड़ा अजीब है: WildInvestment शायद ही किसी चीज़ पर निर्भर है। मेरा मतलब है कि अगर PlayRussianRoulette ने काम नहीं किया, तो PlayRussianRoulette भी यही होगा: इसमें रिटर्न कोड नहीं हैं, लेकिन इसे रूलेट खेलना होगा। तो, हम ऐसी प्रतीत होता है कि निराशाजनक स्थिति में क्या कर सकते हैं? जवाब वास्तव में सरल है: एक और स्तर पर होने के नाते DoSomethingWild को अपने स्वयं के अपवाद को फेंकना चाहिए जो इस स्तर से संबंधित है और इसे एक समस्या के मूल स्रोत के रूप में InnerException एक्सेप्शन में लपेटें:

 namespace JetFinance.Strategies { pubilc class WildStrategy { private Random random = new Random(); public void PlayRussianRoulette() { if(DateTime.Now.Second == (random.Next() % 60)) { throw new StrategyException(); } } } public class StrategyException : Exception { /* .. */ } } namespace JetFinance.Investments { public class WildInvestment { WildStrategy _strategy; public WildInvestment(WildStrategy strategy) { _strategy = strategy; } public void DoSomethingWild() { try { _strategy.PlayRussianRoulette(); } catch(StrategyException exception) { throw new FailedInvestmentException("Oops", exception); } } } public class InvestmentException : Exception { /* .. */ } public class FailedInvestmentException : Exception { /* .. */ } } using JetFinance.Investments; void Main() { var foo = new WildStrategy(); var boo = new WildInvestment(foo); try { boo.DoSomethingWild(); } catch(FailedInvestmentException exception) { } } 

एक अपवाद को दूसरे में लपेटने से हम समस्या को आवेदन के एक स्तर को दूसरे में स्थानांतरित करते हैं और इस वर्ग के उपभोक्ता के संदर्भ में अपने काम को अधिक अनुमानित बनाते हैं: Main विधि।

पुन: उपयोग के मुद्दों पर आधारित है

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

अपवाद के प्रकार का चयन करते समय हम एक पहले से बने समाधान का उपयोग कर सकते हैं, अर्थात नाम के साथ एक अपवाद को खोजने के लिए जिसमें समान अर्थ है और इसका उपयोग करें। उदाहरण के लिए, यदि हमें एक पैरामीटर के माध्यम से एक इकाई मिली और हमें यह इकाई पसंद नहीं है, तो हम InvalidArgumentException को फेंक सकते हैं, जो संदेश में त्रुटि का कारण दर्शाता है। यह परिदृश्य विशेष रूप से अच्छा लग रहा है क्योंकि InvalidArgumentException अपवादों के समूह में है, जिन्हें पकड़ा नहीं जा सकता है। हालाँकि, यदि आप कुछ डेटा प्रकारों के साथ काम करते हैं तो InvalidDataException का चुनाव गलत होगा। ऐसा इसलिए है क्योंकि यह प्रकार System.IO क्षेत्र में है, जो संभवतः वह नहीं है जिससे आप निपटते हैं। इस प्रकार, अपने आप को विकसित करने के बजाय मौजूदा प्रकार की खोज करना लगभग हमेशा गलत होगा। कार्यों की एक सामान्य श्रेणी के लिए लगभग कोई अपवाद नहीं हैं। वस्तुतः वे सभी विशिष्ट स्थितियों के लिए हैं और यदि आप उन्हें अन्य मामलों में पुन: उपयोग करते हैं, तो यह असाधारण स्थितियों की वास्तुकला का गंभीर उल्लंघन करेगा। इसके अलावा, एक विशेष प्रकार का एक अपवाद (उदाहरण के लिए, System.IO.InvalidDataException ) एक उपयोगकर्ता को भ्रमित कर सकता है: एक तरफ, वह देखेगा कि अपवाद System.IO नामस्थान से संबंधित है, जबकि दूसरी तरफ से इसे फेंक दिया गया है। एक पूरी तरह से अलग नामस्थान। यदि यह उपयोगकर्ता इस अपवाद को फेंकने के नियमों के बारे में सोचना शुरू कर देता है, तो वह Referenceource.microsoft.com पर जा सकता है और उन सभी स्थानों को खोज सकता है, जहां इसे फेंका गया है :

• internal class System.IO.Compression.Inflater

उपयोगकर्ता यह समझ जाएगा कोई न कोई अंगूठा है इस प्रकार के अपवाद ने उन्हें इस पद्धति के रूप में भ्रमित कर दिया, जिसने इस अपवाद को फेंक दिया, संपीड़न के साथ सौदा नहीं किया।

इसके अलावा, पुन: उपयोग के संदर्भ में, आप बस एक अपवाद बना सकते हैं और इसमें ErrorCode फ़ील्ड घोषित कर सकते हैं। यह एक अच्छा विचार है। आप बस एक ही अपवाद फेंकते हैं, कोड सेट करते हैं, और अपवादों से निपटने के लिए सिर्फ एक catch का उपयोग करते हैं, एक आवेदन की स्थिरता को बढ़ाते हुए, और कुछ नहीं। हालांकि, मेरा मानना ​​है कि आपको इस स्थिति पर फिर से विचार करना चाहिए। बेशक, यह दृष्टिकोण एक तरफ जीवन को आसान बनाता है। हालांकि, दूसरी ओर, आप अपवादों के एक उपसमूह को पकड़ने की संभावना को खारिज कर देते हैं जिसमें कुछ सामान्य विशेषता होती है। उदाहरण के लिए, ArgumentException जो विरासत द्वारा अपवादों का एक गुच्छा एकजुट करती है। एक और गंभीर नुकसान एक बहुत बड़ा और अपठनीय कोड है जो त्रुटि कोड आधारित फ़िल्टरिंग की व्यवस्था करना चाहिए। हालांकि, एक त्रुटि कोड के साथ एक घेरने वाला प्रकार पेश करना अधिक उचित होगा जब किसी उपयोगकर्ता को किसी त्रुटि को निर्दिष्ट करने की परवाह नहीं करनी होगी।

 public class ParserException { public ParserError ErrorCode { get; } public ParserException(ParserError errorCode) { ErrorCode = errorCode; } public override string Message { get { return Resources.GetResource($"{nameof(ParserException)}{Enum.GetName(typeof(ParserError), ErrorCode)}"); } } } public enum ParserError { MissingModifier, MissingBracket, // ... } // Usage throw new ParserException(ParserError.MissingModifier); 

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

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

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

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

 public abstract class ParserException { public abstract ParserError ErrorCode { get; } public override string Message { get { return Resources.GetResource($"{nameof(ParserException)}{Enum.GetName(typeof(ParserError), ErrorCode)}"); } } } public enum ParserError { MissingModifier, MissingBracket } public class MissingModifierParserException : ParserException { public override ParserError ErrorCode { get; } => ParserError.MissingModifier; } public class MissingBracketParserException : ParserException { public override ParserError ErrorCode { get; } => ParserError.MissingBracket; } // Usage throw new MissingModifierParserException(ParserError.MissingModifier); 

इस दृष्टिकोण का उपयोग करके हमें कुछ अद्भुत गुण मिलते हैं:

• एक ओर, हम एक आधार (सामान्य) प्रकार का उपयोग करके अपवादों को पकड़ते रहते हैं;
• दूसरी ओर, इस आधार प्रकार के अपवादों को पकड़ने पर भी हम एक विशिष्ट स्थिति की पहचान करने में सक्षम हैं;
• इसके अलावा, हम कक्षाओं के फ्लैट संरचना का उपयोग किए बिना आधार प्रकार के बजाय एक विशिष्ट प्रकार के अपवादों को पकड़ सकते हैं।

मुझे लगता है कि यह बहुत सुविधाजनक है।

व्यवहार स्थितियों के एक विशिष्ट समूह से संबंधित है

पिछले तर्क के आधार पर हम क्या निष्कर्ष निकाल सकते हैं? आइए उन्हें परिभाषित करने का प्रयास करें।

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

तो, हम एक या दूसरे समूह या परत के इन प्रकारों के आधार पर असाधारण स्थितियों के प्रकार के लिए एक पदानुक्रम का निर्माण कर सकते हैं। इस प्रकार, हम पदानुक्रम में इन प्रकारों के बीच आसानी से नेविगेट करने के लिए एक पकड़ने वाले कोड की अनुमति देते हैं।

आइए निम्नलिखित कोड की जांच करें:

 namespace JetFinance { namespace FinancialPipe { namespace Services { namespace XmlParserService { } namespace JsonCompilerService { } namespace TransactionalPostman { } } } namespace Accounting { /* ... */ } } 

ऐसा क्या है? मुझे लगता है कि नाम स्थान व्यवहारिक स्थितियों के आधार पर स्वाभाविक रूप से अपवादों के प्रकारों को समूहीकृत करने का एक सही तरीका है: जो कुछ विशेष समूहों से संबंधित हैं, उन्हें अपवाद सहित रहना चाहिए। इसके अलावा, जब आप एक विशेष अपवाद प्राप्त करते हैं, तो आप इसके प्रकार का नाम देखेंगे और इसके नाम स्थान को भी निर्दिष्ट करेंगे जो इसके अंतर्गत आता है। क्या आपको याद है कि InvalidDataException के खराब पुन: उपयोग को वास्तव में System.IO नामस्थान में परिभाषित किया गया है? तथ्य यह है कि यह नामस्थान से तात्पर्य है कि इस प्रकार के अपवाद को उन कक्षाओं से फेंका जा सकता है जो System.IO नामस्थान या अधिक नेस्टेड में हैं। लेकिन वास्तविक अपवाद को पूरी तरह से अलग स्थान से फेंक दिया गया था, इस मुद्दे को संभालने वाले व्यक्ति को भ्रमित कर रहा था। हालाँकि, यदि आप अपवादों के प्रकारों और उन प्रकारों को रखते हैं, जो इन अपवादों को समान नामस्थानों में फेंकते हैं, तो आप प्रकारों की संरचना को सुसंगत बनाए रखते हैं और डेवलपर्स के लिए यह आसान बनाते हैं कि वे क्या होते हैं उसके कारणों को समझें।

कोड के स्तर पर समूह बनाने का दूसरा तरीका क्या है? विरासत:

 public abstract class LoggerExceptionBase : Exception { protected LoggerException(..); } public class IOLoggerException : LoggerExceptionBase { internal IOLoggerException(..); } public class ConfigLoggerException : LoggerExceptionBase { internal ConfigLoggerException(..); } 

ध्यान दें कि सामान्य अनुप्रयोग संस्थाओं के लिए, वे व्यवहार और डेटा और समूह प्रकार दोनों को विरासत में देते हैं जो कि एकल समूह से संबंधित हैं। हालाँकि, अपवादों के लिए, उन्हें विरासत में मिला है और स्थितियों के एक समूह के आधार पर समूहीकृत किया गया है , क्योंकि अपवाद का सार एक इकाई नहीं है, बल्कि एक समस्या है।

इन दो समूहीकरण विधियों को मिलाकर हम निम्नलिखित निष्कर्ष निकाल सकते हैं:

• Assembly अंदर एक आधार प्रकार का अपवाद होना चाहिए जो इस विधानसभा द्वारा फेंका जाएगा। इस प्रकार के अपवाद विधानसभा के मूल नाम स्थान में होने चाहिए। यह ग्रुपिंग की पहली परत होगी।
• इसके अलावा, एक विधानसभा के अंदर एक या कई नाम स्थान हो सकते हैं। उनमें से प्रत्येक विधानसभा को कार्यात्मक क्षेत्रों में विभाजित करता है, स्थितियों के समूहों को परिभाषित करता है, जो इस विधानसभा में दिखाई देते हैं। ये नियंत्रकों, डेटाबेस संस्थाओं, डेटा प्रोसेसिंग एल्गोरिदम, आदि के क्षेत्र हो सकते हैं। हमारे लिए, इन नामस्थानों का अर्थ है उनके कार्य के आधार पर समूहीकरण प्रकार। हालांकि, अपवादों के संदर्भ में वे एक ही विधानसभा के भीतर समस्याओं पर आधारित होते हैं;
• अपवादों को एक ही उच्च-स्तरीय नेमस्पेस में प्रकारों से विरासत में प्राप्त किया जाना चाहिए। यह सुनिश्चित करता है कि अंत उपयोगकर्ता परिस्थितियों को स्पष्ट रूप से समझेगा और गलत प्रकार के अपवादों को नहीं पकड़ेगा। स्वीकार करते हैं, यह global::Finiki.Logistics.OhMyException पकड़ने के लिए अजीब होगा global::Finiki.Logistics.OhMyException by catch(global::Legacy.LoggerExeption exception) , जबकि निम्नलिखित कोड बिल्कुल उपयुक्त लगता है:

 namespace JetFinance.FinancialPipe { namespace Services.XmlParserService { public class XmlParserServiceException : FinancialPipeExceptionBase { // .. } public class Parser { public void Parse(string input) { // .. } } } public abstract class FinancialPipeExceptionBase : Exception { } } using JetFinance.FinancialPipe; using JetFinance.FinancialPipe.Services.XmlParserService; var parser = new Parser(); try { parser.Parse(); } catch (XmlParserServiceException exception) { // Something is wrong in the parser } catch (FinancialPipeExceptionBase exception) { // Something else is wrong. Looks critical because we don't know the real reason } 

यहां, उपयोगकर्ता कोड एक पुस्तकालय विधि कहता है, जैसा कि हम जानते हैं, कुछ स्थिति में XmlParserServiceException को फेंक सकता है। और, जैसा कि हम जानते हैं, यह अपवाद विरासत में मिला नामस्थान JetFinance.FinancialPipe.FinancialPipeExceptionBase , जिसका अर्थ है कि कुछ अन्य अपवाद भी हो सकते हैं - इस समय XmlParserService केवल एक अपवाद बनाता है, लेकिन अन्य अपवाद भविष्य में दिखाई दे सकते हैं। जैसा कि हमारे पास अपवादों के प्रकार बनाने के लिए एक सम्मेलन है, हम जानते हैं कि इस नए अपवाद को किस इकाई से विरासत में लिया जाएगा और अग्रिम में एक catch वाला catch लगाया जाएगा। यह हमारे लिए अप्रासंगिक सभी चीजों को छोड़ देता है।

इस तरह के पदानुक्रम का निर्माण कैसे करें?

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

किसी त्रुटि के स्रोत के आधार पर

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

• त्रुटि के साथ असुरक्षित कोड कॉल। इस स्थिति को अपवाद के सार्वजनिक संपत्ति में डेटा (उदाहरण के लिए मूल त्रुटि कोड) को सहेजते समय किसी अपवाद या त्रुटि कोड को अपने स्वयं के अपवाद में लपेटकर देखा जा सकता है;
• बाहरी निर्भरता द्वारा कोड की एक कॉल, जिसने अपवादों को हमारे पुस्तकालय द्वारा नहीं पकड़ा जा सकता है क्योंकि वे जिम्मेदारी के क्षेत्र से परे हैं। इस समूह में उन संस्थाओं के तरीकों से अपवाद शामिल हो सकते हैं जिन्हें एक मौजूदा विधि के मापदंडों के रूप में स्वीकार किया गया था या एक वर्ग के निर्माता से अपवादों को शामिल किया गया है जिसे विधि ने बाहरी निर्भरता कहा है। उदाहरण के लिए, हमारी कक्षा की एक विधि ने दूसरी कक्षा की एक विधि को कहा है, जिसका उदाहरण किसी अन्य विधि के मापदंडों के माध्यम से वापस किया गया था। यदि कोई अपवाद इंगित करता है कि हम एक समस्या के स्रोत हैं, तो हमें InnerExcepton में मूल को बनाए रखते हुए अपना स्वयं का अपवाद उत्पन्न करना चाहिए। हालाँकि, अगर हम समझते हैं कि समस्या एक बाहरी निर्भरता के कारण हुई है तो हम इस अपवाद को अनदेखा कर देते हैं क्योंकि हमारे नियंत्रण से परे बाहरी निर्भरता के समूह से संबंधित है;
• हमारा अपना कोड जो गलती से असंगत अवस्था में था। एक अच्छा उदाहरण पाठ पार्सिंग है - कोई बाहरी निर्भरता नहीं, unsafe दुनिया में कोई हस्तांतरण नहीं, लेकिन पार्सिंग की समस्या होती है।

यह अध्याय रूसी से संयुक्त रूप से लेखक द्वारा और पेशेवर अनुवादकों द्वारा अनुवादित किया गया था । आप रूसी या अंग्रेजी से किसी अन्य भाषा में अनुवाद करने में हमारी मदद कर सकते हैं, मुख्यतः चीनी या जर्मन में।

इसके अलावा, अगर आप हमें धन्यवाद देना चाहते हैं, तो आप सबसे अच्छा तरीका यह कर सकते हैं कि हमें गितुब पर एक स्टार देना है या रिपॉजिटरी को फोर्क करना है github / sidristij / dotnetbook ।