.NET के लिए ApplicationException क्या है?

Question

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

class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }

और इसी तरह। फिर मैं इन्हें अपने कोड में फेंक देता हूं। लेकिन आज मैं ApplicationExceptionकक्षा में आया - क्या मुझे इसके बजाय इसका उपयोग करना चाहिए? वह किसके लिए है?

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

ApplicationExceptionमेरे कोड के साथ कहां फिट होना चाहिए ?

Comments

बड़ा सवाल है, यह भी चतुराई से नाम नमूना अपवाद के लिए +1

— कोड़ी ग्रे

संबंधित: stackoverflow.com/questions/16603065/… ।

Answer 1

Msdn में टिप्पणी के अनुसार :

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

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

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

Comments

तो ऐसा लगता है कि ApplicationExceptionयह बेकार है और क्या केवल पिछड़ी संगतता के कारण है?

— बीटल्स 1692

नया MSDN प्रलेखन, कम से कम 4.7.2, इस टिप्पणी को याद करता है। Qutoe के लिए धन्यवाद: D

— एलेक्स

Answer 2

संक्षिप्त उत्तर है: कहीं नहीं।

यह अतीत का एक अवशेष है, जहां Microsoft का उद्देश्य डेवलपर्स को ApplicationException से उनके सभी कस्टम अपवादों को प्राप्त करना है। कुछ समय बाद, उन्होंने अपना दिमाग बदल दिया और सलाह दी कि कस्टम अपवाद को बेस एक्सेप्शन क्लास से निकाला जाए। MSDN पर अपवादों को संभालने के लिए सर्वोत्तम अभ्यास देखें ।

इसके लिए अधिक व्यापक रूप से प्रसारित कारणों में से एक जेफरी रिक्टर से फ्रेमवर्क डिज़ाइन दिशानिर्देशों में शामिल है :

System.ApplicationException एक ऐसी क्लास है जो .NET फ्रेमवर्क का हिस्सा नहीं होना चाहिए। मूल विचार यह था कि SystemException से प्राप्त कक्षाएं , CLR (या सिस्टम) से फेंके गए अपवादों को इंगित करेंगी , जबकि गैर-CLR अपवादों को ApplicationException से लिया जाएगा । हालाँकि, बहुत सारे अपवाद वर्ग इस पैटर्न का पालन नहीं करते थे। उदाहरण के लिए, TargetInvocationException (जिसे CLR द्वारा फेंका गया है) ApplicationException से लिया गया है । तो, ApplicationException वर्ग ने सभी अर्थ खो दिए। इस बेस क्लास से व्युत्पन्न होने का कारण बेस क्लास को पकड़ने के लिए कुछ कोड को कॉल स्टैक से ऊपर करने की अनुमति देना है। सभी एप्लिकेशन अपवादों को पकड़ना अब संभव नहीं था।

इसलिए यह अब आपके पास है। कार्यकारी सारांश यह है कि ApplicationException हानिकारक नहीं है , बस बेकार है ।

Comments

क्या किसी को पता है कि क्यों है? ऐसा लगता है कि यह समझ में आएगा ताकि आप ऐप अपवादों को प्रदर्शित कर सकें लेकिन "प्रोग्रामर खराब नहीं हुए" अपवाद।

— जोश कोडरॉफ

बीटीडब्ल्यू, यह इस स्पष्टीकरण से लगता है कि यह प्रति सेकेन्ड खराब नहीं है, लेकिन एमएसएफटी ने कार्यान्वयन को खराब कर दिया है। क्या कोई और इसी तरह पढ़ता है?

— जोश कोड्रॉफ

@JoshKodroff: मुझे लगता है कि मुद्दा यह है कि यदि आवेदन Whizbangयह तय करता है कि वह कुछ सामान्य पदानुक्रम के तहत अपने सभी अपवादों को प्राप्त करना चाहता है, तो ApplicationExceptionइस उद्देश्य के लिए कस्टम WhizbangExceptionबेस क्लास का उपयोग करने पर वास्तव में कोई लाभ नहीं मिलेगा । .Net के अपवाद पदानुक्रम में अधिक गंभीर समस्या ApplicationException, हालांकि, संभवतया-अनुप्रयोग-घातक, संभवतः-थ्रेड-घातक और स्थानीय-समस्या-संबंधित श्रेणियों में अपवादों को अलग करने में विफलता के साथ-साथ असमर्थता है सार्थक "समग्र" अपवाद।

— सुपरकैट

@JoshKodroff: एक उचित रूप से डिज़ाइन किए गए अपवाद ढांचे में, IMHO, यदि एक अपवाद finallyब्लॉक के दौरान फेंक दिया जाता है, जबकि एक अन्य अपवाद लंबित है, catchतो कॉल स्टैक को ब्लॉक किया जाना चाहिए यदि वे किसी भी नेस्टेड अपवाद से मेल खाते हैं, लेकिन अन्य अपवाद को छोड़ दें ताकि बाहर निकलना बंद हो जाए एक catchब्लॉक catchउसी tryब्लॉक (यदि कोई उपयुक्त हो) के भीतर एक और ब्लॉक के लिए आगे बढ़ेगा , और finallyकिसी भी अपवाद के साथ ब्लॉक से बाहर निकलने से अगले बाहरी catchया कूद जाएगा finally।

— सुपरकैट

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

— ओस्कर बरगग्रेन

Answer 3

प्रारंभिक डिजाइन में, .NET 1.0 में, यह योजना बनाई गई थी कि फ्रेमवर्क खुद ही फेंक SystemExceptionऔर व्युत्पन्न होगा; जबकि उपयोगकर्ता अनुप्रयोग - फेंक ApplicationExceptionऔर व्युत्पन्न होंगे।

लेकिन बाद में, .NET 2.0 में, इसे हटा दिया गया था।

इस प्रकार से प्राप्त होता है Exception।