टीएल; डीआर - नहीं , आपको चुपचाप अपवादों को नजरअंदाज नहीं करना चाहिए।
आइए धारणाओं को देखें।
मैंने विश्वास करना सीखा है कि .NET में बहुत से निर्णय ऐसे लोगों द्वारा किए गए थे जो वास्तव में जानते हैं कि वे क्या कर रहे हैं, और आमतौर पर वे तय करने के पीछे एक बहुत अच्छा कारण है। लेकिन यह मुझे बचता है।
MS के पास वास्तव में कर्मचारियों पर कुछ शानदार लोग हैं, इसमें कोई संदेह नहीं है। उनके पास कई प्रबंधक और अधिकारी भी हैं जो हैं ... क्लूलेस, और जो लगातार खराब निर्णय लेते हैं। उत्पाद विकास की तकनीकी रूप से जानकार वैज्ञानिक की परियों की कहानी पर हम जितना विश्वास करना चाहते हैं, वास्तविकता उससे कहीं अधिक गंभीर है।
मेरा कहना है, अगर आपकी वृत्ति आपको बताती है कि कुछ गलत हो सकता है तो एक अच्छा मौका है (और पिछले मिसाल) कि यह गलत है।
इस मामले में अपवादों को कैसे संभालना एक मानवीय कारक निर्णय है, न कि तकनीकी निर्णय। शिथिल, एक अपवाद एक त्रुटि है। त्रुटि की प्रस्तुति, भले ही खराब स्वरूपित हो, अंतिम उपयोगकर्ता को महत्वपूर्ण जानकारी प्रदान करती है। अर्थात्, कुछ गलत हो गया।
उपयोगकर्ता और अंतिम उपयोगकर्ता और डेवलपर के बीच की इस काल्पनिक बातचीत पर विचार करें।
उपयोगकर्ता: एप्लिकेशन टूट गया है।
देव: क्या टूटा है?
उपयोगकर्ता: मुझे पता नहीं है, मैं बटन पर क्लिक करता हूं और कुछ भी नहीं होता है।
देव: क्या मतलब है तुम्हारा कुछ नहीं होता?
उपयोगकर्ता: देखो, मैं क्लिक करता हूं, मैं प्रतीक्षा करता हूं, और मैं प्रतीक्षा करता हूं, और मैं प्रतीक्षा करता हूं, और कुछ भी नहीं ... यह स्पष्ट रूप से टूट गया है।
हमारे गरीब, सौभाग्य से काल्पनिक डेवलपर को अब यह पता लगाना है कि घटनाओं की श्रृंखला में क्या गलत हुआ। यह कहां था?
इवेंट हैंडलर नोटिफिकेशन -> रूटीन को ईवेंट को हैंडल करने के लिए -> हैंडलर द्वारा ट्रिगर की गई विधि -> एसिंक्रोनस कॉल की शुरुआत -> OSI नेटवर्किंग की 7 लेयर्स -> फिजिकल ट्रांसमिशन -> OSI नेटवर्किंग की 7 लेयर्स का बैकअप लें -> सर्विस -> सेवा द्वारा बुलाया विधि -> ... -> सेवा द्वारा भेजा गया वापसी उत्तर -> .... -> asynch रसीद -> asynch उत्तर का प्रसंस्करण>> ...
और कृपया ध्यान दें कि मैंने वहाँ कई संभावित त्रुटि पथों पर काम किया है।
कुछ अंतर्निहित धारणाओं को संबोधित करने के बाद, मुझे लगता है कि यह अधिक स्पष्ट हो जाता है कि चुपचाप अपवादों को क्यों दबा देना एक बुरा विचार है। एक अपवाद और संबंधित त्रुटि संदेश उपयोगकर्ताओं के लिए एक महत्वपूर्ण संकेतक है कि कुछ गलत हो गया है। भले ही संदेश अंत उपयोगकर्ता के लिए अर्थहीन हो, एम्बेडेड जानकारी डेवलपर के लिए उपयोगी हो सकती है यह समझने में कि क्या गलत हुआ। यदि वे भाग्यशाली हैं, तो संदेश भी समाधान की ओर ले जाएगा।
मुझे लगता है कि इस समस्या का एक हिस्सा यह है कि एक गलत तरीके से संभाला गया अपवाद आपके एप्लिकेशन को क्रैश कर देगा। अपवादों को दबाने से, एप्लिकेशन क्रैश नहीं होगा। इसके लिए कुछ वैधता है, हालांकि चूंकि एसिंक्स का बिंदु एप्लिकेशन को काम करते रहने की अनुमति देना है, जबकि डेटा पुनर्प्राप्त किया जा रहा है। यह कहना ज्यादा तर्कसंगत नहीं है कि अगर आप नतीजों का इंतजार करते हुए काम कर सकते हैं, तो रिट्रीवल में असफलता या तो एप्लिकेशन को क्रैश नहीं कर सकती है - इस async कॉल को स्पष्ट रूप से घोषित किया जाता है, ताकि आवेदन समाप्त करने के लिए पर्याप्त महत्वपूर्ण न हो।
तो यह एक समाधान है, लेकिन यह गलत समस्या को हल कर रहा है। यह अपवाद को संभालने के लिए एक आवरण प्रदान करने के लिए इतना प्रयास नहीं करता है ताकि आवेदन चालू रह सके। अपवाद पकड़ा गया है, त्रुटि संदेश स्क्रीन या फेंक दिया गया है, और एप्लिकेशन को चालू रखने की अनुमति है। अपवाद को दबाने से तात्पर्य यह है कि त्रुटियों को अनदेखा करने से ए-ओके होने वाला है और आपके परीक्षण से यह सुनिश्चित हो जाएगा कि अपवाद कभी भी क्षेत्र में नहीं बचेंगे।
इसलिए मेरा अंत मूल्यांकन यह है कि लोगों को एक अतुल्यकालिक मॉडल में धकेल कर बनाई गई समस्या को हल करने का यह एक अर्ध-बेक्ड प्रयास है जब वे अपनी सोच को उस दृष्टिकोण में स्थानांतरित करने के लिए तैयार नहीं थे।