अपवाद शोर को कम करने के लिए कुछ सुझाव

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

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

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

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

नेटवर्क बंद है!

कुछ ऐप्स अकेले काम करते हैं। अधिकांश अन्य ऐप्स के साथ संवाद करते हैं। लेकिन जब आपका जियोलोकेशन एपीआई नीचे चला जाता है या ec2 में हिचकी आती है, तो आप ऐसे हजारों अपवादों के साथ स्पैम नहीं करना चाहते हैं जिनके बारे में आप कुछ नहीं कर सकते।

जब आप अविश्वसनीय सेवाओं से निपटते हैं, तो सर्किट ब्रेकर पैटर्न आज़माएं , माइकल न्यागार्ड की रिलीज़ इट से:

सर्किट ब्रेकर के पीछे मूल विचार बहुत सरल है। आप एक संरक्षित फ़ंक्शन कॉल को सर्किट ब्रेकर ऑब्जेक्ट में लपेटते हैं, जो विफलताओं की निगरानी करता है। एक बार जब विफलताएं एक निश्चित सीमा तक पहुंच जाती हैं, तो सर्किट ब्रेकर ट्रिप, और सर्किट ब्रेकर को आगे की सभी कॉल एक त्रुटि के साथ वापस आ जाती हैं, बिना प्रोटेक्टेड कॉल किए।

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

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

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

इससे पता चलता है कि gmaaaail.com आपका मतलब नहीं है

एक अन्य प्रकार का अपवाद जो मैंने देखा है वह खराब उपयोगकर्ता डेटा से आता है।

उदाहरण के लिए, मान लें कि किसी ने साइन अप करते समय अपना ईमेल टाइप किया था। उन्होंने कहा, "justinweiss@gmaill.com", लेकिन इसका मतलब "justinweiss@gmail.com" था। पहला सैद्धांतिक रूप से एक वैध ईमेल पता हो सकता है, लेकिन आपके द्वारा भेजे गए सभी ईमेल बाउंस हो जाते हैं। और आपको अपने ईमेल प्रदाता द्वारा उन बाउंस के बारे में सूचित किया जाता है।

ये सूचनाएं केवल शोर हैं।

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

ईमेल के लिए, जब नए उपयोगकर्ता पंजीकरण करते हैं, तो मैंने "gmail.com" और "yahoo.com" जैसी चीज़ों की वर्तनी जाँचने के लिए mailcheck-js रत्न का उपयोग किया है:

{% img img-responsive /images/posts/email-spellcheck.gif 477 451 ओह, फैंसी। %}

फिर, यदि कोई ईमेल बाद में भी बाउंस होता है, तो उस उपयोगकर्ता को ईमेल बंद कर दें।

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

आपको बेहतर डेटा मिलेगा, और उपयोगकर्ता के ईमेल खाली नहीं जाएंगे। उन त्रुटियों से कहीं बेहतर है जिन्हें आप अभी-अभी नज़रअंदाज़ कर रहे हैं।

404s और रूटिंग त्रुटियाँ

आप शायद अपनी साइट पर टूटे लिंक या संपत्ति के बारे में जानना चाहते हैं। लेकिन वे चीजें आपके अपवाद ट्रैकर में नहीं हैं।

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

रूटिंग एरर और 404 जैसी चीजों को Google वेबमास्टर टूल्स जैसी किसी चीज़ से नियंत्रित किया जा सकता है, जो आपको उन पेजों को दिखाएगा जिनके बारे में Google जानता है कि 404 फेंक रहे हैं। या आप अपनी पूर्व-रिलीज़ प्रक्रिया के हिस्से के रूप में अपनी साइट पर लिंक की जाँच करने के लिए लिंक-चेकर जैसा कुछ चला सकते हैं।

अपवाद कार्रवाई योग्य होने चाहिए

अपवाद ईमेल प्राप्त करना दुर्लभ होना चाहिए। आपके त्रुटि ट्रैकर में बहुत अधिक शोर आपको वास्तविक समस्याओं को तुरंत देखने और ठीक करने से रोकेगा।

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

मैंने कुछ शोर अपवाद श्रेणियों के बारे में बात की है जिन्हें मैंने अक्सर देखा है। लेकिन मुझे यकीन है कि मैंने उन सभी को नहीं देखा है। आपके ऐप्स में कौन से अपवाद आपको सबसे अधिक परेशान करते हैं? क्या वे इनमें से किसी भी श्रेणी में फिट होते हैं, या क्या वे एक नई श्रेणी को परिभाषित करते हैं? आप उन्हें दिन में कुछ सौ बार आपको परेशान करने से कैसे बचाते हैं?