जावास्क्रिप्ट त्रुटि हैंडलिंग गाइड

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



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

यह जावास्क्रिप्ट त्रुटि हैंडलिंग सामग्री तीन भागों में विभाजित है। सबसे पहले, हम जावास्क्रिप्ट में त्रुटि हैंडलिंग प्रणाली का एक सामान्य अवलोकन देंगे और त्रुटि वस्तुओं के बारे में बात करेंगे। उसके बाद, हम इस सवाल के जवाब की तलाश करते हैं कि सर्वर कोड में होने वाली त्रुटियों के साथ क्या करना है (विशेष रूप से, जब Node.js + Express.js बंडल का उपयोग करते हैं)। अगला, हम React.js में त्रुटि हैंडलिंग पर चर्चा करते हैं। यहां जिन रूपरेखाओं पर विचार किया जाएगा, वे उनकी अत्यधिक लोकप्रियता के कारण चुनी गई हैं। हालाँकि, यहां चर्चा की गई त्रुटियों के साथ काम करने के सिद्धांत सार्वभौमिक हैं, इसलिए यदि आप एक्सप्रेस और रिएक्ट का उपयोग नहीं करते हैं, तो भी आप आसानी से लागू कर सकते हैं कि आपने अपने साथ काम करने वाले टूल से क्या सीखा।

इस सामग्री में प्रयुक्त डेमो प्रोजेक्ट का कोड इस रिपॉजिटरी में पाया जा सकता है।

1. जावास्क्रिप्ट में त्रुटियां और उनके साथ काम करने के सार्वभौमिक तरीके

यदि आपके कोड में कुछ गलत हुआ है, तो आप निम्नलिखित निर्माण का उपयोग कर सकते हैं।

throw new Error('something went wrong') 

इस कमांड के निष्पादन के दौरान, त्रुटि ऑब्जेक्ट का एक उदाहरण बनाया जाएगा और इस ऑब्जेक्ट के साथ एक अपवाद उत्पन्न होगा (या, जैसा कि वे कहते हैं, "फेंक दिया")। फेंक बयान मनमाने ढंग से अभिव्यक्ति वाले अपवादों को फेंक सकता है। इस स्थिति में, स्क्रिप्ट का निष्पादन बंद हो जाएगा यदि त्रुटि को संभालने के लिए उपाय नहीं किए गए हैं।

शुरुआती जेएस प्रोग्रामर आमतौर पर throw स्टेटमेंट का उपयोग नहीं करते हैं। वे आमतौर पर भाषा रनटाइम या थर्ड-पार्टी लाइब्रेरी द्वारा फेंके गए अपवादों का सामना करते हैं। जब ऐसा होता है, एक ReferenceError: fs is not defined तरह कुछ कंसोल में हो जाता है ReferenceError: fs is not defined और प्रोग्राम निष्पादन बंद हो जाता है।

BObject त्रुटि

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

 const myError = new Error('please improve your code') console.log(myError.message) // please improve your code 

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

 Error: please improve your code at Object.<anonymous> (/Users/gisderdube/Documents/_projects/hacking.nosync/error-handling/src/general.js:1:79) at Module._compile (internal/modules/cjs/loader.js:689:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10) at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) at Function.Module.runMain (internal/modules/cjs/loader.js:742:12) at startup (internal/bootstrap/node.js:266:19) at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3) 

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

▍ जनरेशन और एरर हैंडलिंग

Error ऑब्जेक्ट का एक उदाहरण बनाना, जो कि फॉर्म की एक Error को निष्पादित करता है new Error() , किसी विशेष परिणाम के लिए नेतृत्व नहीं करता है। throw ऑपरेटर लगाने के बाद दिलचस्प चीजें शुरू होती हैं, जो एक त्रुटि उत्पन्न करता है। जैसा कि पहले ही उल्लेख किया गया है, यदि ऐसी त्रुटि संसाधित नहीं होती है, तो स्क्रिप्ट निष्पादन बंद हो जाएगा। इस मामले में, इससे कोई फर्क नहीं पड़ता है कि प्रोग्रामर द्वारा खुद throw ऑपरेटर का उपयोग किया गया था या नहीं, एक निश्चित लाइब्रेरी में या भाषा रनटाइम में (ब्राउज़र में या Node.js में) कोई त्रुटि हुई। आइए विभिन्न त्रुटि हैंडलिंग परिदृश्यों के बारे में बात करते हैं।

▍संकट की कोशिश ... पकड़

try...catch अक्सर भूल गए त्रुटियों को संभालने का सबसे आसान तरीका है। आजकल, हालांकि, इसका उपयोग पहले की तुलना में बहुत अधिक गहन रूप से किया जाता है, इस तथ्य के कारण कि इसका उपयोग async/await निर्माण में त्रुटियों को संभालने के लिए किया जा सकता है।

इस ब्लॉक का उपयोग तुल्यकालिक कोड में होने वाली किसी भी त्रुटि को संभालने के लिए किया जा सकता है। एक उदाहरण पर विचार करें।

 const a = 5 try {   console.log(b) //  b   -   } catch (err) {   console.error(err) //          } console.log(a) //    ,    

यदि इस उदाहरण में हमने असफल console.log(b) कमांड को एक try...catch में संलग्न नहीं किया है try...catch , स्क्रिप्ट को रोक दिया जाएगा।

▍ अंत में ब्लॉक करें

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

 const a = 5 try {   console.log(b) //  b   -   } catch (err) {   console.error(err) //          } finally {   console.log(a) //        } 

▍एसिन्क्रोनस तंत्र - कॉलबैक

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

 myAsyncFunc(someInput, (err, result) => {   if(err) return console.error(err) //           console.log(result) }) 

यदि कॉलबैक में कोई त्रुटि होती है, तो यह एक गलत पैरामीटर के रूप में दिखाई देता है। अन्यथा, इस पैरामीटर को मान undefined या null मिलेगा। यदि यह पता चलता है कि err कुछ है, तो इस पर प्रतिक्रिया करना महत्वपूर्ण है क्योंकि हमारे उदाहरण में, return कमांड का उपयोग करते हुए, या if...else का उपयोग करते हुए और असिंक्रोनस ऑपरेशन के परिणाम के साथ काम करने के लिए else ब्लॉक में कमांड का if...else और रखते हैं। मुद्दा यह है कि इस घटना में, एक त्रुटि होती है, परिणाम के साथ काम करने की संभावना को बाहर कर देता है, result पैरामीटर, जो इस मामले में undefined हो सकता है। इस मान के साथ कार्य करना, यदि यह माना जाता है, उदाहरण के लिए, कि इसमें कोई ऑब्जेक्ट है, तो स्वयं त्रुटि हो सकती है। मान लें कि ऐसा तब होता है जब आप result.data निर्माण या result.data समान result.data का उपयोग करने का प्रयास करते हैं।

▍एसिन्क्रोनस मैकेनिज्म - वादे

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

 (node:7741) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: something went wrong (node:7741) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. */ 

नतीजतन, आप हमेशा अनुशंसा कर सकते हैं, जब वादों के साथ काम करना, catch का उपयोग करना। एक उदाहरण देखें।

 Promise.resolve(1)   .then(res => {       console.log(res) // 1       throw new Error('something went wrong')       return Promise.resolve(2)   })   .then(res => {       console.log(res) //        })   .catch(err => {       console.error(err) //  ,     ,         return Promise.resolve(3)   })   .then(res => {       console.log(res) // 3   })   .catch(err => {       //      ,      -        console.error(err)   }) 

▍Asynchronous तंत्र और कोशिश ... पकड़

जावास्क्रिप्ट में async/await निर्माण दिखाई देने के बाद, हम त्रुटियों को संभालने के क्लासिक तरीके पर लौटे - try...catch...finally । इस दृष्टिकोण के साथ त्रुटियों को संभालना बहुत आसान और सुविधाजनक है। एक उदाहरण पर विचार करें।

 ;(async function() {   try {       await someFuncThatThrowsAnError()   } catch (err) {       console.error(err) //       }   console.log('Easy!') //   })() 

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

2. सर्वर कोड में त्रुटियों को उत्पन्न करना और संसाधित करना

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

रूटिंग के लिए जिम्मेदार सर्वर फ्रेमवर्क के रूप में, हम Express.js का उपयोग करेंगे। आइए विचार करें कि एक प्रभावी त्रुटि हैंडलिंग प्रणाली को व्यवस्थित करने के लिए हमें किस संरचना की आवश्यकता है। तो यहाँ है कि हम क्या जरूरत है:

1. यूनिवर्सल एरर हैंडलिंग किसी भी त्रुटि को संभालने के लिए उपयुक्त कुछ बुनियादी तंत्र है, जिसके दौरान Something went wrong, please try again or contact us जैसा संदेश Something went wrong, please try again or contact us , उपयोगकर्ता को उस ऑपरेशन को करने का प्रयास करने के लिए कहें जो विफल हो गया, फिर से या सर्वर के मालिक से संपर्क करें। यह प्रणाली विशेष रूप से बुद्धिमान नहीं है, लेकिन कम से कम यह उपयोगकर्ता को सूचित करने में सक्षम है कि कुछ गलत हो गया। ऐसा संदेश "अंतहीन डाउनलोड" या कुछ इसी तरह से बेहतर है।
2. विशिष्ट त्रुटियों को संसाधित करना - एक तंत्र जो आपको उपयोगकर्ता को अनुचित प्रणाली व्यवहार के कारणों के बारे में विस्तृत जानकारी देने और उसे समस्या से निपटने के तरीके के बारे में विशिष्ट सलाह देने की अनुमति देता है। उदाहरण के लिए, यह उपयोगकर्ता को सर्वर को भेजने वाले अनुरोध में कुछ महत्वपूर्ण डेटा की अनुपस्थिति की चिंता कर सकता है, या डेटाबेस में पहले से ही एक निश्चित रिकॉर्ड है जिसे वह फिर से जोड़ने की कोशिश कर रहा है, और इसी तरह।

। त्रुटि वस्तुओं के अपने स्वयं के निर्माता का विकास करना

यहां हम मानक Error वर्ग का उपयोग करेंगे और इसे विस्तारित करेंगे। जावास्क्रिप्ट में विरासत तंत्र का उपयोग करना जोखिम भरा है, लेकिन इस मामले में, ये तंत्र बहुत उपयोगी हैं। हमें विरासत की आवश्यकता क्यों है? तथ्य यह है कि हमारे लिए कोड को आसानी से डिबग करने के लिए, हमें त्रुटि स्टैक के निशान के बारे में जानकारी चाहिए। मानक Error वर्ग का विस्तार करते हुए, हमें अतिरिक्त प्रयास के बिना स्टैक का पता लगाने की क्षमता मिलती है। हम अपनी त्रुटि वस्तु में दो गुण जोड़ते हैं। पहला code प्रॉपर्टी है, जिसे फॉर्म err.code की संरचना का उपयोग करके एक्सेस किया जा सकता है। दूसरा status प्रॉपर्टी है। यह HTTP स्थिति कोड रिकॉर्ड करेगा, जिसे एप्लिकेशन के क्लाइंट भाग में प्रेषित करने की योजना है।

यह वही है जो CustomError वर्ग जैसा दिखता है, जिसका कोड एक मॉड्यूल के रूप में डिज़ाइन किया गया है।

 class CustomError extends Error {   constructor(code = 'GENERIC', status = 500, ...params) {       super(...params)       if (Error.captureStackTrace) {           Error.captureStackTrace(this, CustomError)       }       this.code = code       this.status = status   } } module.exports = CustomError 

▍ रूटिंग

अब जब हमारी त्रुटि ऑब्जेक्ट उपयोग के लिए तैयार है, तो हमें मार्ग संरचना को कॉन्फ़िगर करने की आवश्यकता है। जैसा कि ऊपर उल्लेख किया गया है, हमें त्रुटि हैंडलिंग के लिए एक एकीकृत दृष्टिकोण को लागू करने की आवश्यकता है, जो हमें सभी मार्गों के लिए समान रूप से त्रुटियों को संभालने की अनुमति देता है। डिफ़ॉल्ट रूप से, Express.js ढांचा ऐसी योजना का पूरी तरह से समर्थन नहीं करता है। तथ्य यह है कि इसके सभी मार्ग संक्षिप्त हैं।

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

 {   error: 'SOME_ERROR_CODE',   description: 'Something bad happened. Please try again or contact support.' } 

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

यह मार्ग हैंडलर कोड जैसा दिखता है।

 const express = require('express') const router = express.Router() const CustomError = require('../CustomError') router.use(async (req, res) => {   try {       const route = require(`.${req.path}`)[req.method]       try {           const result = route(req) //    route           res.send(result) //   ,     route       } catch (err) {           /*                ,    route             */           if (err instanceof CustomError) {               /*                   -                                  */               return res.status(err.status).send({                   error: err.code,                   description: err.message,               })           } else {               console.error(err) //                  //   -                   return res.status(500).send({                   error: 'GENERIC',                   description: 'Something went wrong. Please try again or contact support.',               })           }       }   } catch (err) {       /*          ,    ,  ,            ,  ,          ,                       */       res.status(404).send({           error: 'NOT_FOUND',           description: 'The resource you tried to access does not exist.',       })   } }) module.exports = router 

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

अब मार्ग फ़ाइल पर एक नज़र डालें।

 const CustomError = require('../CustomError') const GET = req => {   //       return { name: 'Rio de Janeiro' } } const POST = req => {   //       throw new Error('Some unexpected error, may also be thrown by a library or the runtime.') } const DELETE = req => {   //  ,      throw new CustomError('CITY_NOT_FOUND', 404, 'The city you are trying to delete could not be found.') } const PATCH = req => {   //      CustomError   try {       //   -        throw new Error('Some internal error')   } catch (err) {       console.error(err) //    ,           throw new CustomError(           'CITY_NOT_EDITABLE',           400,           'The city you are trying to edit is not editable.'       )   } } module.exports = {   GET,   POST,   DELETE,   PATCH, } 

इन उदाहरणों में, प्रश्नों के साथ कुछ भी नहीं किया जाता है। यह केवल त्रुटियों की घटना के लिए विभिन्न परिदृश्यों पर विचार करता है। इसलिए, उदाहरण के लिए, GET /city अनुरोध const GET = req =>... function में गिर जाएगा const GET = req =>... , POST /city अनुरोध const POST = req =>... function में गिर जाएगा const POST = req =>... और इसी तरह। क्वेरी मापदंडों का उपयोग करते समय यह योजना भी काम करती है। उदाहरण के लिए, फॉर्म GET /city?startsWith=R अनुरोध के लिए GET /city?startsWith=R सामान्य तौर पर, यह प्रदर्शित किया जाता है कि जब प्रसंस्करण त्रुटियां होती हैं, तो फ्रंटेंड या तो सामान्य त्रुटि प्राप्त कर सकता है जिसमें केवल फिर से कोशिश करने या सर्वर के मालिक से संपर्क करने की पेशकश होती है, या CustomError निर्माता का उपयोग करके उत्पन्न एक त्रुटि होती है जिसमें समस्या के बारे में विस्तृत जानकारी होती है।
सामान्य त्रुटि डेटा निम्न रूप में आवेदन के ग्राहक भाग में आएगा:

 {   error: 'GENERIC',   description: 'Something went wrong. Please try again or contact support.' } 

CustomError कंस्ट्रक्टर का उपयोग इस तरह किया जाता है:

 throw new CustomError('MY_CODE', 400, 'Error description') 

यह निम्नलिखित JSON कोड को फ्रंटेंड में दिया गया है:

 {   error: 'MY_CODE',   description: 'Error description' } 

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

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

3. क्लाइंट पर त्रुटियों के साथ काम करें

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

। आवेदन की स्थिति में त्रुटि की जानकारी दें

किसी भी अन्य डेटा की तरह, त्रुटियों और त्रुटि संदेश बदल सकते हैं, इसलिए उन्हें घटकों की स्थिति में रखना समझ में आता है। जब घटक को माउंट किया जाता है, तो त्रुटि डेटा रीसेट हो जाता है, इसलिए, जब उपयोगकर्ता पहली बार पृष्ठ देखता है, तो कोई त्रुटि संदेश नहीं होगा।

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

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

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

यह प्रतिक्रिया में एप्लिकेशन की स्थिति के प्रबंधन के लिए अंतर्निहित प्रणाली का उपयोग करेगा, लेकिन, यदि आवश्यक हो, तो आप राज्य के प्रबंधन के लिए विशेष समाधान का उपयोग कर सकते हैं - जैसे कि MobX या Redux।

▍ वैश्विक त्रुटियां

आमतौर पर, ऐसे त्रुटि संदेश एक राज्य के साथ उच्चतम-स्तरीय घटक में संग्रहीत होते हैं। वे एक स्थिर उपयोगकर्ता इंटरफ़ेस तत्व में प्रदर्शित होते हैं। यह स्क्रीन के शीर्ष पर एक लाल बॉक्स, एक मोडल विंडो, या कुछ और हो सकता है। कार्यान्वयन विशिष्ट परियोजना पर निर्भर करता है। यह त्रुटि संदेश जैसा दिखता है।


वैश्विक त्रुटि संदेश

अब Application.js फ़ाइल में संग्रहीत कोड पर एक नज़र डालें।

 import React, { Component } from 'react' import GlobalError from './GlobalError' class Application extends Component {   constructor(props) {       super(props)       this.state = {           error: '',       }       this._resetError = this._resetError.bind(this)       this._setError = this._setError.bind(this)   }   render() {       return (           <div className="container">               <GlobalError error={this.state.error} resetError={this._resetError} />               <h1>Handling Errors</h1>           </div>       )   }   _resetError() {       this.setState({ error: '' })   }   _setError(newError) {       this.setState({ error: newError })   } } export default Application 

, , Application.js , . , .

GlobalError , x , . GlobalError ( GlobalError.js ).

 import React, { Component } from 'react' class GlobalError extends Component {   render() {       if (!this.props.error) return null       return (           <div               style={{                   position: 'fixed',                   top: 0,                   left: '50%',                   transform: 'translateX(-50%)',                   padding: 10,                   backgroundColor: '#ffcccc',                   boxShadow: '0 3px 25px -10px rgba(0,0,0,0.5)',                   display: 'flex',                   alignItems: 'center',               }}           >               {this.props.error}                              <i                   className="material-icons"                   style={{ cursor: 'pointer' }}                   onClick={this.props.resetError}               >                   close               </font></i>           </div>       )   } } export default GlobalError 

if (!this.props.error) return null . , . . , , , . , , x , - , .

, , _setError Application.js . , , , , ( error: 'GENERIC' ). ( GenericErrorReq.js ).

 import React, { Component } from 'react' import axios from 'axios' class GenericErrorReq extends Component {   constructor(props) {       super(props)       this._callBackend = this._callBackend.bind(this)   }   render() {       return (           <div>               <button onClick={this._callBackend}>Click me to call the backend</button>           </div>       )   }   _callBackend() {       axios           .post('/api/city')           .then(result => {               //  -     ,               })           .catch(err => {               if (err.response.data.error === 'GENERIC') {                   this.props.setError(err.response.data.description)               }           })   } } export default GenericErrorReq 

, . , , . . -, , -, UX-, , — .

▍ ,

, , , .




, . . . SpecificErrorReq.js .

 import React, { Component } from 'react' import axios from 'axios' import InlineError from './InlineError' class SpecificErrorRequest extends Component {   constructor(props) {       super(props)       this.state = {           error: '',       }       this._callBackend = this._callBackend.bind(this)   }   render() {       return (           <div>               <button onClick={this._callBackend}>Delete your city</button>               <InlineError error={this.state.error} />           </div>       )   }   _callBackend() {       this.setState({           error: '',       })       axios           .delete('/api/city')           .then(result => {               //  -     ,               })           .catch(err => {               if (err.response.data.error === 'GENERIC') {                   this.props.setError(err.response.data.description)               } else {                   this.setState({                       error: err.response.data.description,                   })               }           })   } } export default SpecificErrorRequest 

, , , x . , , . , , — , , , . , , . , , , — .

▍,

, , , . , , - . .


,

SpecificErrorFrontend.js , .

 import React, { Component } from 'react' import axios from 'axios' import InlineError from './InlineError' class SpecificErrorRequest extends Component {   constructor(props) {       super(props)       this.state = {           error: '',           city: '',       }       this._callBackend = this._callBackend.bind(this)       this._changeCity = this._changeCity.bind(this)   }   render() {       return (           <div>               <input                   type="text"                   value={this.state.city}                   style={{ marginRight: 15 }}                   onChange={this._changeCity}               />               <button onClick={this._callBackend}>Delete your city</button>               <InlineError error={this.state.error} />           </div>       )   }   _changeCity(e) {       this.setState({           error: '',           city: e.target.value,       })   }   _validate() {       if (!this.state.city.length) throw new Error('Please provide a city name.')   }   _callBackend() {       this.setState({           error: '',       })       try {           this._validate()       } catch (err) {           return this.setState({ error: err.message })       }       axios           .delete('/api/city')           .then(result => {               //  -     ,               })           .catch(err => {               if (err.response.data.error === 'GENERIC') {                   this.props.setError(err.response.data.description)               } else {                   this.setState({                       error: err.response.data.description,                   })               }           })   } } export default SpecificErrorRequest 

▍

, , ( GENERIC ), , . , , , , , , , , . .

परिणाम

हमें उम्मीद है कि अब आपको वेब अनुप्रयोगों में त्रुटियों से निपटने की समझ होगी। इस तरह के कुछ का console.error(err)उपयोग केवल डिबगिंग उद्देश्यों के लिए किया जाना चाहिए, प्रोग्रामर द्वारा भूल गई ऐसी चीजों को उत्पादन में प्रवेश नहीं करना चाहिए। कुछ उपयुक्त लाइब्रेरी जैसे लॉजवेल का उपयोग करके लॉगिंग की समस्या के समाधान को सरल करता है ।

प्रिय पाठकों! आप अपनी परियोजनाओं में त्रुटियों को कैसे संभालते हैं?