IRO.Mvc.MvcExceptionHandler का उपयोग करके ASP.NET अपवाद को संभालना

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

हम ASP.NET लाइब्रेरी के बारे में बात करेंगे, जो आपको इस समस्या को यथासंभव हल करने की अनुमति देता है। उन लोगों के लिए जो एक लंबा लेख पढ़ने के लिए बहुत आलसी हैं - रीडमी और पुस्तकालय खुद यहां हैं , एक उदाहरण यहां है । Nuget.org पर उपलब्ध है और मुझे केवल तभी खुशी होगी जब इससे किसी को लाभ होगा। और इसलिए, कोड पर चलते हैं। पहले, चलो विकल्पों पर एक नज़र डालते हैं।

अपवादों को संभालने के लिए डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) बनाने के लिए दिमाग में आने वाली पहली चीज़ों में से एक है, नियंत्रक में एक अपवाद को पकड़ना (हालांकि यह आवश्यक नहीं है कि यह एक अपवाद होगा, हो सकता है कि यह केवल अशक्त या ऐसा कुछ जाँच रहा हो) डीटीओ में डेटा भरें और क्लाइंट को भेजें। इस पद्धति का कोड कुछ इस तरह दिखाई दे सकता है:

public IActionResult Get() { try { //Code with exception. } catch (Exception ex) { return new JsonResult( new ErrorDto { IsError = true, Message = ex.Message }); } } 

एक अन्य विकल्प इसके लिए HTTP स्थिति कोड का उपयोग करना है।

 public IActionResult Get() { try { //Code with exception. } catch (Exception ex) { return BadRequest(); } } 

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

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

उपरोक्त के साथ सामना किया गया है, बहुत से इस समस्या को हल करने का प्रयास कर रहे हैं app.UseExceptionHandler (); इसके माध्यम से अपवादों को संभालना। यह एक अच्छा प्रयास है, लेकिन यह आपको समस्या के बारे में आसानी से भूलने नहीं देगा। सबसे पहले, आप अभी भी अपवादों के लिए डीटीओ चुनने की समस्या का सामना करेंगे। दूसरे, ऐसे हैंडलर http त्रुटि कोड को संसाधित करने की अनुमति नहीं देंगे जो नियंत्रकों से वापस किए गए थे, क्योंकि अपवाद नहीं हुआ। तीसरा, इस तरह से यह त्रुटि वर्गीकरण समस्या को हल करने के लिए असुविधाजनक है, आपको एक संदेश, http कोड या प्रत्येक अपवाद के लिए कुछ संलग्न करने के लिए बहुत सारे कोड लिखना होगा। और चौथा, आप AspA DeveloperExceptionPage का उपयोग करने का अवसर खो देते हैं, जो डीबगिंग के लिए बहुत असुविधाजनक है। यहां तक ​​कि अगर आप किसी तरह इस समस्या को हल करते हैं, तो इस परियोजना के सभी डेवलपर्स को विनिर्देशों का कड़ाई से पालन करना होगा, विशेष रूप से अपवादों पर त्रुटि से निपटने का निर्माण करना होगा, अपने डीटीओ को वापस नहीं करना चाहिए, अन्यथा आपके एपीआई में त्रुटियां विधि से विधि में भिन्न हो सकती हैं।

चयनित अपवाद हैंडलिंग विकल्प

इससे पहले कि मैं दिखाऊं कि IRO.Mvc.MvcExceptionHandler आपको अपवादों को संभालने की अनुमति कैसे देता है, पहले मैं वर्णन करता हूं कि मैं आदर्श संचालन हैंडलिंग कैसे देखता हूं। ऐसा करने के लिए, हम कई आवश्यकताओं को स्थापित करते हैं:

1. यह एक डीटीओ होना चाहिए, लेकिन हम http कोड को भी मना नहीं करते हैं, क्योंकि कई त्रुटियों के लिए, वे अभी भी अच्छी तरह से अनुकूल हैं, हर जगह और एक पुरानी परियोजना में उपयोग किया जा सकता है जिसे आपको भी समर्थन करना होगा, और वे बस सार्वभौमिक हैं। मानक DTO में IsError फ़ील्ड शामिल होगी (जो क्लाइंट पर सार्वभौमिक रूप से त्रुटि को लिखने की अनुमति देता है), इसमें ErrorKey string error कोड भी होना चाहिए, जिसे डेवलपर तुरंत इसे देखकर ही पहचान सकता है और जो अधिक जानकारी प्रदान करता है। इसके अतिरिक्त, यदि आवश्यक हो, तो आप इस त्रुटि के विवरण के साथ एक पृष्ठ पर एक लिंक जोड़ सकते हैं।
2. यह सब ठेस में है। विकास मोड में, इस डीटीओ को स्टैक ट्रेस वापस करना चाहिए, डेटा का अनुरोध करना चाहिए: कुकीज़, हेडर, पैरामीटर। आगे देखते हुए, लेख में वर्णित मिडलवेयर यहां तक ​​कि जेनरेट किए गए DeveloperExceptionPage का लिंक भी लौटाता है, जो आपको एक अपवाद के रूप में एक अपवाद के रूप में अपवाद को देखने की अनुमति देता है, लेकिन बाद में उस पर और अधिक।
3. डेवलपर अपवाद, http त्रुटि कोड और ErrorKey को एक साथ बांध सकता है। इसका मतलब यह है कि यदि वह नियंत्रक से 403 कोड भेजता है, तो अगर डेवलपर ने इसे एक विशेष ErrorKey संलग्न किया है, तो इसके साथ डीटीओ वापस आ जाएगा। और इसके विपरीत, अगर एक अनधिकृत असफलता होती है, तो यह http कोड और ErrorKey के लिए बाध्य होगी।

यह लाइब्रेरी में उपयोग किया जाने वाला डिफ़ॉल्ट प्रारूप है:

 { "__IsError": true, "ErrorKey": "ClientException", "InfoUrl": "https://iro.com/errors/ClientException" } 

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

IRO.Mvc.MvcExceptionHandler

अब मैं दिखाऊंगा कि IRO.Mvc.MvcExceptionHandler लाइब्रेरी लिखकर मैंने अपने लिए इस समस्या को कैसे हल किया।

हम अपवाद हैंडलर को किसी अन्य मिडलवेयर की तरह कनेक्ट करते हैं - स्टार्टअप क्लास में।

 app.UseMvcExceptionHandler((s) => { //Settings... }); 

प्रत्यायोजित प्रतिनिधि के अंदर, हमें अपने मिडलवेयर को कॉन्फ़िगर करने की आवश्यकता है। Http कोड और ErrorKey अपवादों को मैप (बाइंड) करना आवश्यक है। नीचे सबसे आसान सेटअप विकल्प है।

  s.Mapping((builder) => { builder.RegisterAllAssignable<Exception>( httpCode: 500, errorKeyPrefix: "Ex_" ); }); 

जैसा कि मैंने सबसे आलसी कट्टर डेवलपर्स से वादा किया था जो अपवादों को संभालने के लिए उपयोग नहीं किए जाते हैं - कुछ और करने की आवश्यकता नहीं है। यह कोड ASP.NET पाइपलाइन के सभी अपवादों को कोड 500 के साथ सामान्य DTO में बाँध देगा, और अपवाद का नाम ErrorKey लिखा जाएगा।

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

आप एक विशिष्ट अपवाद के लिए अपने ErrorKey और http कोड को ठीक कर सकते हैं और पंजीकृत कर सकते हैं:

  s.Mapping((builder) => { //By exception, custom error key. builder.Register<ArgumentNullException>( httpCode: 555, errorKey: "CustomErrorKey" ); //By http code. builder.Register( httpCode: 403, errorKey: "Forbidden" ); //By exception, default ErrorKey and http code. builder.Register<NullReferenceException>(); //Alternative registration method. builder.Register((ErrorInfo) new ErrorInfo() { ErrorKey = "MyError", ExceptionType = typeof(NotImplementedException), HttpCode = 556 }); }); 

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

  s.ErrorDescriptionUrlHandler = new FormattedErrorDescriptionUrlHandler("https://iro.com/errors/{0}"); s.IsDebug = isDebug; s.DefaultHttpCode = 500; s.JsonSerializerSettings.Formatting = Formatting.Indented; s.Host="https://iro.com"; s.CanBindByHttpCode = true; 

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

  s.InnerExceptionsResolver = InnerExceptionsResolvers.InspectAggregateException; 

यदि आपको सीरियल-ट्यून ठीक करने की आवश्यकता है, तो आप FilterAfterDTO विधि सेट कर सकते हैं। मानक प्रसंस्करण को अक्षम करने के लिए सही लौटें और अपनी पसंद के अनुसार errorContext.ErrorDTO को अनुक्रमित करें। HttpContext और स्वयं त्रुटि तक पहुँच है।

  s.FilterAfterDTO = async (errorContext) => { //Custom error handling. Return true if MvcExceptionHandler must ignore current error, //because it was handled. return false; }; 

DeveloperExceptionPage और डीबग मोड के अन्य फायदे

हमने सेटिंग्स का पता लगा लिया है, अब आइए जानें कि यह सब कैसे डिबग करें। डीटीओ ठेस में, जवाब में जवाब सरल है और मैंने पहले ही इसे ऊपर दिखाया था, अब मैं दिखाऊंगा कि कैसे डीटीओ डिबग मोड में दिखता है:



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



इस फ़ंक्शन को लागू करना कठिन था, जैसा कि DeveloperExceptionPage को केवल तृतीय-पक्ष डेवलपर्स द्वारा उपयोग किए जाने का इरादा नहीं है। प्रारंभ में, एक अलग सत्र के साथ ब्राउज़र में लिंक को खोलना असंभव था, एक रिबूट के बाद प्रदर्शित होने वाली सामग्री बंद हो गई। यह सब इस बिचौलिए की html प्रतिक्रिया को कैशिंग द्वारा ही हल किया जा सकता है। यदि आप एक साझा समर्पित सर्वर का उपयोग करते हैं तो आप कम से कम अपने टीम के साथी को अपवाद लिंक पास कर सकते हैं।

निष्कर्ष

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