डीडीडी में अपवादों के साथ कैसे काम करें

हाल ही में DotNext 2018 सम्मेलन के भाग के रूप में, डोमेन ड्रिवेन डिज़ाइन पर BoF हुआ। इसने अपवादों के साथ काम करने के मुद्दे को संबोधित किया, जिसने एक गर्म बहस का कारण बना, लेकिन एक विस्तृत चर्चा प्राप्त नहीं की, क्योंकि यह मुख्य विषय नहीं था।

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

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

इस बारे में अलग-अलग राय है कि क्या अपने स्वयं के प्रकार का अपवाद बनाना है या .NET में दिए गए मानक लोगों का उपयोग करना है।

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

इस लेख में मैं हमारी टीम द्वारा अपनाई गई प्रथाओं के बारे में बात करूंगा (संक्षेप में - हम सभी दृष्टिकोणों का उपयोग करते हैं और उनमें से कोई भी हठधर्मिता नहीं है)।

हम ASP.NET MVC + WebAPI के आधार पर निर्मित एंटरप्राइज़ एप्लिकेशन के बारे में बात करेंगे। एप्लिकेशन को प्याज आर्किटेक्चर बनाया गया है, डेटाबेस और संदेश ब्रोकर के साथ संचार करता है। यह ELK स्टैक में संरचित लॉगिंग का उपयोग करता है और ग्राफ्टाना का उपयोग करके निगरानी को कॉन्फ़िगर किया गया है।

हम तीन दृष्टिकोणों के अपवादों के साथ काम करेंगे:

1. सामान्य अपवाद नियम
2. अपवाद, त्रुटियां, और प्याज वास्तुकला
3. वेब अनुप्रयोगों के लिए विशेष मामले

सामान्य अपवाद नियम

1. अपवाद और त्रुटियां एक ही चीज नहीं हैं। अपवादों के लिए हम अपवादों का उपयोग करते हैं, त्रुटियों के लिए - परिणाम।
2. अपवाद केवल असाधारण स्थितियों के लिए हैं, जो परिभाषा के अनुसार कई नहीं हो सकते। तो कम अपवाद, बेहतर।
3. अपवाद हैंडलिंग यथासंभव दानेदार होनी चाहिए। जैसा कि रिक्टर ने अपने स्मारकीय कार्य में लिखा था।
4. यदि त्रुटि को उपयोगकर्ता को उसके मूल रूप में दिया जाना चाहिए - परिणाम का उपयोग करें।
5. एक अपवाद को सिस्टम की सीमाओं को उसके मूल रूप में नहीं छोड़ना चाहिए। यह उपयोगकर्ता के अनुकूल नहीं है और हमलावर को सिस्टम में संभावित कमजोरियों का पता लगाने का एक तरीका देता है।
6. यदि फेंके गए अपवाद को हमारे अनुप्रयोग द्वारा नियंत्रित किया जाता है, तो हम अपवाद नहीं, बल्कि परिणाम का उपयोग करते हैं। अपवादों पर कार्यान्वयन गोटो ऑपरेटर द्वारा छिपाया जाएगा और इससे भी बदतर यह होगा कि अपवाद फेंक कोड से प्रसंस्करण कोड दूर है। परिणाम स्पष्ट रूप से एक त्रुटि की संभावना की घोषणा करता है और केवल इसकी "रैखिक" प्रसंस्करण की अनुमति देता है।

अपवाद, त्रुटियां, और प्याज वास्तुकला

निम्नलिखित अनुभागों में, हम निम्नलिखित परतों के लिए अपवाद / त्रुटियों को फेंकने / संभालने के लिए जिम्मेदारियों और नियमों पर विचार करेंगे:

• अनुप्रयोग होस्ट करता है
• इंफ्रास्ट्रक्चर
• अनुप्रयोग सेवाएँ
• डोमेन कोर

अनुप्रयोग होस्ट

इसके लिए कौन जिम्मेदार है

• संपूर्ण अनुप्रयोग के संचालन को कस्टमाइज़ करने वाली रचना ।
• बाहरी दुनिया के साथ बातचीत की सीमा उपयोगकर्ताओं, अन्य सेवाओं, अनुसूचित लॉन्च है।

चूंकि ये काफी जटिल जिम्मेदारियां हैं, इसलिए उन्हें खुद को सीमित करने के लिए लायक है। हम शेष जिम्मेदारियों को आंतरिक परतों को देते हैं।

रिजल्ट से त्रुटियों को कैसे संभालें

बाहरी दुनिया में प्रसारण, उपयुक्त प्रारूप में परिवर्तित करना (उदाहरण के लिए, http प्रतिक्रिया में)।

परिणाम कैसे उत्पन्न होता है

कोई रास्ता नहीं। इस परत में तर्क नहीं है, इसलिए त्रुटियाँ उत्पन्न करने के लिए कहीं नहीं है।

अपवादों को कैसे संभालें

1. विवरण छिपाता है और बाहरी दुनिया को भेजने के लिए उपयुक्त प्रारूप में कनवर्ट करता है
2. लॉग इन करता है।

अपवाद कैसे फेंके

कोई रास्ता नहीं, यह परत सबसे बाहरी है और इसमें तर्क नहीं है - इसके अपवाद को फेंकने वाला कोई नहीं है।

इंफ्रास्ट्रक्चर

इसके लिए कौन जिम्मेदार है

1. बंदरगाहों , या बस डोमेन-इंटरफेस को लागू करने के लिए अनुकूली, बुनियादी ढांचे तक पहुंच प्रदान करना - तृतीय-पक्ष सेवाएं, डेटाबेस, सक्रिय निर्देशिका, आदि। यह परत जितना संभव हो उतना बेवकूफ होना चाहिए और यथासंभव कम तर्क युक्त होना चाहिए।
2. यदि आवश्यक हो, तो यह भ्रष्टाचार-विरोधी परत के रूप में कार्य कर सकता है।

रिजल्ट से त्रुटियों को कैसे संभालें

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

परिणाम कैसे उत्पन्न होता है

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

अपवादों को कैसे संभालें

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

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

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

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

1. स्पष्ट रूप से अनुबंध में त्रुटियों की संभावना की घोषणा करें।
2. हमें उस स्थिति से छुटकारा मिलता है जब एप्लिकेशन सेवा त्रुटि को संभालना जानती है, लेकिन अपवाद के प्रकार को नहीं जानती है, क्योंकि यह एक विशिष्ट संदेश ब्रोकर से सार है। आधार पर एक कैच ब्लॉक बनाने के लिए System.Exception का अर्थ है कि सभी प्रकार के अपवादों को पकड़ना, और न कि केवल उन जो अनुप्रयोग सेवा संभाल सकते हैं।

अपवाद कैसे फेंके

सिस्टम की बारीकियों पर निर्भर करता है।

उदाहरण के लिए, सिंगल और फर्स्ट LINQ स्टेटमेंट एक अमान्य डेटा का अनुरोध करते समय InvalidOperationException को फेंक देते हैं। लेकिन इस प्रकार के अपवाद का उपयोग .NET में हर जगह किया जाता है, जो इसे बारीक रूप से संसाधित करना असंभव बनाता है।

हमने टीम में एक कस्टम ItemNotFoundException बनाने और इसे बुनियादी ढांचे की परत से फेंकने की प्रथा को अपनाया, यदि अनुरोधित डेटा नहीं मिला और व्यावसायिक नियमों के अनुसार ऐसा नहीं होना चाहिए।

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

अनुप्रयोग सेवाएँ

इसके लिए कौन जिम्मेदार है

1. इनपुट डेटा की मान्यता।
2. ऑर्केस्ट्रेशन और सेवाओं का समन्वय - लेनदेन की शुरुआत और अंत, वितरित लिपियों का कार्यान्वयन, आदि।
3. डोमेन कोर में कमांड के बाद कॉल, इन्फ्रास्ट्रक्चर के लिए बंदरगाहों के माध्यम से डोमेन-ऑब्जेक्ट और बाहरी डेटा डाउनलोड करें।

रिजल्ट से त्रुटियों को कैसे संभालें

डोमेन कोर से त्रुटियाँ बाहरी दुनिया में अपरिवर्तित हैं। इंफ्रास्ट्रक्चर से त्रुटियों को रिट्री, सर्किट ब्रेकर नीतियों या बाहर प्रसारित करने के माध्यम से नियंत्रित किया जा सकता है।

परिणाम कैसे उत्पन्न होता है

परिणाम को सत्यापन के रूप में लागू कर सकते हैं।

ऑपरेशन की आंशिक सफलता की सूचना उत्पन्न कर सकते हैं। उदाहरण के लिए, "आपका आदेश सफलतापूर्वक दिया गया है जैसे उपयोगकर्ता को संदेश, लेकिन वितरण पते को सत्यापित करते समय एक त्रुटि हुई। डिलीवरी विवरण को स्पष्ट करने के लिए एक विशेषज्ञ जल्द ही आपसे संपर्क करेगा। "

अपवादों को कैसे संभालें

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

अपवाद कैसे फेंके

सामान्य तौर पर, कोई रास्ता नहीं। लेकिन लेख के अंतिम खंड में वर्णित सीमावर्ती विकल्प हैं।

डोमेन कोर

इसके लिए कौन जिम्मेदार है

व्यावसायिक तर्क का कार्यान्वयन, सिस्टम का "मूल" और इसके अस्तित्व का मुख्य अर्थ है।

रिजल्ट से त्रुटियों को कैसे संभालें

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

परिणाम कैसे उत्पन्न होता है

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

अपवादों को कैसे संभालें

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

अपवाद कैसे फेंके

आमतौर पर एक सामान्य नियम यहां काम करता है: कम अपवाद - बेहतर।

लेकिन क्या आपके पास कभी ऐसी परिस्थितियां होती हैं जब आप कोड लिखते हैं और समझते हैं कि कुछ शर्तों के तहत यह भयानक व्यवसाय कर सकता है? उदाहरण के लिए, पैसे को दो बार लिखने या डेटा को इतना खराब करने के लिए कि फिर हम हड्डियों को इकट्ठा नहीं कर सकते।

एक नियम के रूप में, हम उन कमांड को निष्पादित करने के बारे में बात कर रहे हैं जो ऑब्जेक्ट की वर्तमान स्थिति के लिए अस्वीकार्य हैं।

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

कुछ जाँचों को सत्यापन स्तर पर अनुप्रयोग सेवाओं में रखा जा सकता है। लेकिन यह रक्षात्मक प्रोग्रामिंग में बदल सकता है, जो चरम मामलों में निम्नलिखित की ओर जाता है:

1. एन्कैप्सुलेशन को कमजोर किया जाता है, क्योंकि बाहरी परत पर कुछ अपरिवर्तनों का सत्यापन होना चाहिए।
2. बाहरी क्षेत्र में विषय क्षेत्र "प्रवाह" का ज्ञान; जांच दोनों परतों द्वारा दोहराया जा सकता है।
3. एक बाहरी परत से कमांड के निष्पादन को मान्य करना यह सत्यापित करने से अधिक जटिल और कम विश्वसनीय हो सकता है कि एक डोमेन ऑब्जेक्ट अपने वर्तमान स्थिति में एक कमांड निष्पादित नहीं कर सकता है ।

इसके अलावा, यदि हम इस तरह की जांच को सत्यापन परत में रखते हैं, तो हमें उपयोगकर्ता को त्रुटि का कारण बताना होगा। यह देखते हुए कि हम एक ऐसे ऑपरेशन के बारे में बात कर रहे हैं जो वर्तमान परिस्थितियों में बिल्कुल भी नहीं किया जा सकता है, हम दो स्थितियों में से एक होने का जोखिम चलाते हैं:

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

लेकिन लेख के मुख्य विषय पर वापस जाएं। सभी संकेतों से, चर्चा के तहत स्थिति असाधारण है। ऐसा कभी नहीं होना चाहिए, लेकिन अगर ऐसा होता है, तो यह बुरा होगा।

इस स्थिति में एक अपवाद को फेंकना, आवश्यक विवरणों को गिरवी रखना, उपयोगकर्ता के लिए सामान्य रूप "ऑपरेशन संभव नहीं है" पर लौटना, इस प्रकार की त्रुटियों के लिए निगरानी स्थापित करना और उम्मीद करना कि हम उन्हें कभी नहीं देखेंगे।

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

वेब अनुप्रयोगों के लिए विशेष मामले

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

इसके अलावा, अनुरोध को संसाधित करने के बाद, एक प्रतिक्रिया हमेशा उत्पन्न होती है। यदि हमारे कोड द्वारा निष्पादित ऑपरेशन डेटा वापस नहीं करता है, तो प्लेटफ़ॉर्म अभी भी स्थिति कोड वाली प्रतिक्रिया वापस कर देगा। यदि ऑपरेशन एक अपवाद द्वारा निरस्त कर दिया गया था, तो प्लेटफ़ॉर्म अभी भी एक प्रतिक्रिया देगा जिसमें संबंधित स्थिति कोड होगा।

इस व्यवहार को लागू करने के लिए, वेब प्लेटफार्मों में प्रसंस्करण पाइप के रूप में बनाया गया है। पहले, अनुरोध को क्रमिक रूप से संसाधित किया जाता है (अनुरोध), और फिर प्रतिक्रिया तैयार की जाती है।

हम मिडलवेयर, एक्शन फ़िल्टर, http हैंडलर या ISAPI फ़िल्टर (प्लेटफ़ॉर्म पर निर्भर करता है) का उपयोग कर सकते हैं और किसी भी चरण में इस पाइपलाइन में एकीकृत कर सकते हैं। और अनुरोध प्रसंस्करण के किसी भी स्तर पर, हम प्रसंस्करण को बाधित कर सकते हैं और पाइपलाइन एक प्रतिक्रिया बनाने के लिए आगे बढ़ेगा।

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

यह सब आपको अपवाद से निपटने के लिए क्या करना है, आप पूछें?

तथ्य यह है कि लेख के पिछले हिस्सों में वर्णित अपवादों के साथ काम करने के नियम इस परिदृश्य में अच्छी तरह से फिट नहीं होते हैं।

अपवाद का उपयोग करना बुरा है क्योंकि यह गोटो शब्दार्थ है।

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

ऐसी स्थिति में क्या करें?

एक निरपेक्ष का निर्माण न करें। हम नियमों को अपने लाभ के लिए निर्धारित करते हैं, न कि निरोध के लिए।

यदि आप किसी ऑपरेशन को निरस्त करना चाहते हैं क्योंकि इसकी निरंतरता असंभव है, तो अपवाद को फेंकने से गोटो शब्दार्थ नहीं होगा। हम बाहर निकलने के लिए निष्पादन को निर्देशित करते हैं, और व्यवसाय कोड के किसी अन्य ब्लॉक को नहीं।

यदि वांछित स्थिति कोड को निर्धारित करने के लिए रुकावट का कारण महत्वपूर्ण है, तो कस्टम अपवाद प्रकार का उपयोग किया जा सकता है।

इससे पहले, हमने दो कस्टम प्रकारों का उल्लेख किया था जिनका हम उपयोग करते हैं: ItemNotFoundException (404 में बदलना) और CorruptedInvariant (500 में बदलना)।

यदि आप उपयोगकर्ताओं के अधिकारों की जांच करते हैं, क्योंकि वे रोल मॉडल पर नहीं आते हैं या दावा नहीं करते हैं, तो यह एक कस्टम फॉरबिडेनसेप्शन (स्थिति कोड 403) बनाने की अनुमति है।

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

वह सब है। आप अपवादों के साथ कैसे काम करते हैं?