एक अच्छा अपवाद संदेश कैसे लिखें


101

मैं वर्तमान में एक कोड की समीक्षा कर रहा हूं और जिन चीजों को मैं देख रहा हूं उनमें से एक अपवाद की संख्या है जहां अपवाद संदेश सिर्फ अपवाद को दोहराता है जहां अपवाद हुआ। जैसे

throw new Exception("BulletListControl: CreateChildControls failed.");

इस संदेश में सभी तीन आइटम मैं अपवाद के बाकी हिस्सों से काम कर सकता हूं। मैं स्टैक ट्रेस से वर्ग और विधि जानता हूं और मुझे पता है कि यह विफल रहा है (क्योंकि मुझे एक अपवाद मिला है)।

इसने मुझे यह सोचने पर मजबूर कर दिया कि मैंने अपवाद संदेशों में क्या संदेश दिया। पहले मैं एक अपवाद वर्ग बनाता हूं, अगर कोई पहले से ही मौजूद नहीं है, तो सामान्य कारण (जैसे PropertyNotFoundException- क्यों ), और फिर जब मैं इसे फेंकता हूं तो यह संदेश इंगित करता है कि क्या गलत हुआ (उदाहरण के लिए "संपत्ति खोजने में असमर्थ 'नोड 1234 पर' IDontExist ' "- क्या )। जहां में है StackTraceजब (यदि लागू हो) लॉग में हो सकता है। कैसे है डेवलपर बाहर काम करने के लिए (और ठीक)

क्या आपके पास अपवादों को फेंकने के लिए कोई और सुझाव है? विशेष रूप से नए प्रकार और अपवाद संदेश बनाने के संबंध में।


4
क्या ये लॉग फ़ाइलों के लिए या उपयोगकर्ता के लिए प्रस्तुत करने के लिए हैं?
जॉन हॉपकिंस

5
केवल डिबगिंग के लिए। वे एक लॉग में समाप्त हो सकते हैं। उन्हें उपयोगकर्ता के सामने प्रस्तुत नहीं किया जाएगा। मैं उपयोगकर्ता को अपवाद संदेश प्रस्तुत करने का प्रशंसक नहीं हूं।
कॉलिन मैके

जवाबों:


70

मैं एक अपवाद के बाद जो आता है, उसके लिए अपने उत्तर को और अधिक निर्देशित करूँगा: यह किसके लिए अच्छा है और सॉफ़्टवेयर को कैसे व्यवहार करना चाहिए, आपके उपयोगकर्ताओं को अपवाद के साथ क्या करना चाहिए? मेरे करियर की शुरुआत में आई एक शानदार तकनीक हमेशा समस्याओं और त्रुटियों को 3 भागों में रिपोर्ट करना था: संदर्भ, समस्या और समाधान। इस dicipline के उपयोग से त्रुटि से निपटने में भारी परिवर्तन होता है और यह ऑपरेटर के उपयोग के लिए सॉफ़्टवेयर को बहुत बेहतर बनाता है।

यहाँ कुछ उदाहरण हैं।

Context: Saving connection pooling configuration changes to disk.
Problem: Write permission denied on file '/xxx/yyy'.
Solution: Grant write permission to the file.

इस स्थिति में, ऑपरेटर को ठीक से पता होता है कि क्या करना है और किस फ़ाइल को प्रभावित करना है। वे यह भी जानते हैं कि कनेक्शन पूलिंग परिवर्तन नहीं हुआ था और इसे दोहराया जाना चाहिए।

Context: Sending email to 'abc@xyz.com' regarding 'Blah'.
Problem: SMTP connection refused by server 'mail.xyz.com'.
Solution: Contact the mail server administrator to report a service problem.  The email will be sent later. You may want to tell 'abc@xyz.com' about this problem.

मैं सर्वर साइड सिस्टम लिखता हूं और मेरे ऑपरेटर आमतौर पर टेक सेवी फर्स्ट लाइन सपोर्ट करते हैं। मैं डेस्कटॉप सॉफ़्टवेयर के लिए अलग तरह से संदेश लिखता हूं जिसमें एक अलग दर्शक होता है लेकिन एक ही जानकारी शामिल होती है।

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

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

एक कंपनी में हमारे पास शीर्ष पायदान ऑपरेटर थे जो सॉफ्टवेयर को अच्छी तरह से जानते थे और अपनी खुद की "रन बुक" रखते थे जिसने हमारी त्रुटि रिपोर्टिंग और समाधान का सुझाव दिया। इसे पहचानने के लिए सॉफ्टवेयर को अपवादों में रन बुक के लिए विकी लिंक सहित शुरू किया गया ताकि समय के साथ ऑपरेटरों द्वारा अधिक उन्नत चर्चा और टिप्पणियों के लिए एक बुनियादी स्पष्टीकरण उपलब्ध हो सके।

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


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

3
+1 के लिए मुझे शामिल है, संदर्भ, समस्या, समाधान का समाधान पसंद है
WebDev

1
यह तकनीक इतनी मददगार है। मैं निश्चित रूप से इसका उपयोग करने जा रहा हूं।
किड डायमंड

संदर्भ अनावश्यक डेटा है। यह पहले से ही स्टैक ट्रेस में मौजूद है। बीत रहा है समाधान बेहतर लेकिन हमेशा संभव नहीं / उपयोगी है। अधिकांश समस्याएं एक तरह से इनायत से आवेदन को रोकने या लंबित संचालन को अनदेखा करने और मुख्य निष्पादन लूप को वापस करने की उम्मीद करते हुए होती है कि अगली बार जब आप सफल होते हैं ... अपवाद वर्ग का नाम ऐसा होना चाहिए कि समाधान स्पष्ट हो जाएगा, FileNotFoundया ConnectExceptionआप जानते हैं कि क्या करना है)
गवेंको

2
@ThomasFlinkow आपके उदाहरण में निशान init (), निष्पादित () और स्टैक ट्रेस में क्लीनअप () होगा। पुस्तकालय और स्वच्छ / समझने योग्य एपीआई में अच्छे नामकरण स्कीमा के साथ आपको स्ट्रिंग स्पष्टीकरण की आवश्यकता नहीं है। और तेजी से विफल, पूरे सिस्टम में टूटी हुई स्थिति को न ले जाएं। विशिष्ट आईडी के साथ निशान और लॉगिंग रिकॉर्ड आवेदन प्रवाह / स्थिति की व्याख्या कर सकते हैं।
गवेंको

23

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

अपवाद का "संदेश" अपवाद का (पूरी तरह से योग्य) वर्ग नाम है।

एक अपवाद को अपने स्वयं के सदस्य चर के भीतर होना चाहिए, जैसा कि वास्तव में हुआ था; उदाहरण के लिए, एक IndexOutOfRangeExceptionअनुक्रमणिका मान होना चाहिए जो अमान्य पाया गया था, साथ ही साथ ऊपरी और निचले मान जो इस समय मान्य थे कि अपवाद फेंक दिया गया था। इस तरह, प्रतिबिंब का उपयोग करने से आपके पास एक संदेश स्वतः निर्मित हो सकता है जो इस तरह से पढ़ता है: IndexOutOfRangeException: index = -1; min=0; max=5और यह, स्टैक ट्रेस के साथ, सभी उद्देश्यपूर्ण जानकारी होनी चाहिए जो आपको समस्या का निवारण करने के लिए चाहिए। इसे एक सुंदर संदेश में बदलना जैसे "इंडेक्स -1 0 और 5 के बीच नहीं था" कोई मूल्य नहीं जोड़ता है।

आपके विशेष उदाहरण में, NodePropertyNotFoundExceptionवर्ग में उस संपत्ति का नाम होगा जो नहीं मिली थी, और नोड के लिए एक संदर्भ जिसमें संपत्ति नहीं थी। यह महत्वपूर्ण है: इसमें नोड का नाम नहीं होना चाहिए ; इसमें वास्तविक नोड का संदर्भ होना चाहिए। आपके विशेष मामले में यह आवश्यक नहीं हो सकता है, लेकिन यह सिद्धांत का मामला है और सोचने का एक पसंदीदा तरीका है: अपवाद का निर्माण करते समय प्राथमिक चिंता यह है कि यह कोड द्वारा उपयोग करने योग्य होना चाहिए जो इसे पकड़ सकता है। मनुष्यों द्वारा उपयोगिता एक महत्वपूर्ण, लेकिन केवल माध्यमिक चिंता है।

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

बेशक, चूंकि अपवाद का वर्ग नाम अपवाद का संदेश है, (और अपवाद के सदस्य चर विशिष्ट विवरण हैं), इसका मतलब है कि आपको सभी अलग-अलग संदेशों को व्यक्त करने के लिए बहुत सारे और बहुत सारे अपवादों की आवश्यकता है, और यह ठीक है।

अब, कभी-कभी, जैसा कि हम कोड लिखते हैं, हम एक गलत स्थिति में आ जाते हैं, जिसके लिए हम बस एक throwस्टेटमेंट को जल्दी से कोड करना चाहते हैं और अपने कोड को लिखने के लिए आगे बढ़ने के बजाय हम एक नया अपवाद वर्ग बनाने के लिए क्या कर रहे हैं ताकि हम कर सकें इसे वहीं फेंक दो। इन मामलों के लिए, मेरे पास एक GenericExceptionवर्ग है जो वास्तव में एक निर्माण-समय पैरामीटर के रूप में एक स्ट्रिंग संदेश को स्वीकार करता है, लेकिन इस अपवाद वर्ग के निर्माता को एक बड़ी बड़ी उज्ज्वल बैंगनी FIXME XXX TODOटिप्पणी के साथ सुशोभित किया गया है, जिसमें कहा गया है कि इस वर्ग की हर एक तात्कालिकता होनी चाहिए सॉफ़्टवेयर सिस्टम जारी होने से पहले कुछ और विशेष अपवाद वर्ग के एक पल के साथ प्रतिस्थापित किया जाता है, अधिमानतः कोड होने से पहले।


8
यदि आप ऐसी भाषा में हैं, जिसमें C ++ की तरह GC नहीं है, तो आपको मनमाने ढंग से डेटा को अपवादों में डालने के बारे में बहुत सावधानी बरतनी चाहिए जो आप स्टैक को भेजते हैं। संभावना है, जो भी आप संदर्भित कर रहे हैं वह उस समय तक नष्ट हो जाता है जब अपवाद पकड़ा जाता है।
सेबेस्टियन रेडल

4
@ सेबेस्टियनरेडल सच। और वही C # और जावा पर लागू हो सकता है यदि nodeऑब्जेक्ट का उपयोग कर-डिस्पोजेबल (C # में) या संसाधनों के साथ-साथ (जावा में) क्लॉज द्वारा संरक्षित है: अपवाद के साथ संग्रहित वस्तु का निपटान / बंद किया जाएगा, जिससे यह अवैध हो जाएगा किसी भी उपयोगी जानकारी को उस स्थान पर पहुँचाने के लिए जहां अपवाद को संभाला जाता है, वहां तक ​​पहुँचने के लिए। मुझे लगता है कि इन मामलों में वस्तु के सारांश को किसी वस्तु के बजाय अपवाद के भीतर संग्रहित किया जाना चाहिए। मैं सभी मामलों के लिए इसे मूल रूप से संभालने के लिए एक मूर्ख-प्रूफ तरीका नहीं सोच सकता।
माइक नाकिस

13

एक सामान्य नियम के रूप में, एक अपवाद को डेवलपर्स को उपयोगी जानकारी (अपेक्षित मान, वास्तविक मूल्य, संभावित कारण / समाधान, आदि) देकर कारण बताने में मदद करनी चाहिए

नए अपवाद प्रकार तब बनाए जाने चाहिए जब कोई भी अंतर्निहित प्रकार समझ में न आए । एक विशिष्ट प्रकार अन्य डेवलपर्स को एक विशिष्ट अपवाद को पकड़ने और इसे संभालने में सक्षम बनाता है। यदि डेवलपर को पता होगा कि आपके अपवाद को कैसे संभालना है Exception, लेकिन प्रकार है , तो वह इसे ठीक से संभाल नहीं पाएगा।


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

4

.NET में कभी नहीं throw new Exception("...")(जैसे प्रश्न के लेखक ने दिखाया है)। अपवाद रूट अपवाद प्रकार है और इसे सीधे सीधे फेंका नहीं जाना चाहिए। इसके बजाय व्युत्पन्न .NET अपवाद प्रकारों में से एक को फेंक दें या अपना स्वयं का कस्टम अपवाद बनाएं जो अपवाद (या अन्य अपवाद प्रकार) से प्राप्त होता है।

अपवाद क्यों नहीं? क्योंकि अपवाद को फेंकना आपके अपवाद का वर्णन करने के लिए कुछ भी नहीं करता है और आपके कॉलिंग कोड को कोड लिखने के लिए मजबूर catch(Exception ex) { ... }करता है जो आमतौर पर एक अच्छी बात नहीं है! :-)।


2

जिन चीज़ों को आप अपवाद में "जोड़ना" चाहते हैं, वे डेटा के ऐसे तत्व हैं जो अपवाद या स्टैक ट्रेस में अंतर्निहित नहीं हैं। चाहे वे "संदेश" का हिस्सा हों या लॉग इन करते समय संलग्न होने की आवश्यकता एक दिलचस्प सवाल है।

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

इसलिए ... या तो .NET के लिए सूचीबद्ध या, लॉग किए गए अपवाद डेटा संग्रह में जोड़ा गया (cf @Plip!)।

  • पैरामीटर (यह थोड़ा दिलचस्प हो सकता है - आप डेटा संग्रह में जोड़ नहीं सकते हैं यदि यह क्रमबद्ध नहीं होगा और कभी-कभी एक भी पैरामीटर आश्चर्यजनक रूप से जटिल हो सकता है)
  • अतिरिक्त डेटा ADO.NET या Linq द्वारा SQL या इसी तरह लौटाया गया है (यह भी थोड़ा दिलचस्प हो सकता है!)।
  • जो कुछ और स्पष्ट नहीं हो सकता है।

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


0

अपवाद क्या हैं के लिए ?

(१) उपयोगकर्ता को यह बताना कि कुछ गलत हुआ है?

यह एक अंतिम उपाय होना चाहिए, क्योंकि आपके कोड को हस्तक्षेप करना चाहिए और उन्हें अपवाद के बजाय कुछ "अच्छे" दिखाना चाहिए।

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

जैसे "कृपया इस बटन को फिर से दबाएं नहीं"

(२) गलत होने पर डेवलपर को बताना?

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

(३) एक अपवाद हैंडलर (यानी कोड) को बताना कि कुछ गलत हुआ?

अपवाद का प्रकार यह तय करेगा कि किस अपवाद हैंडलर को इसे देखने के लिए मिलेगा और अपवाद वस्तु पर परिभाषित गुण हैंडलर को इससे निपटने की अनुमति देगा।

अपवाद का संदेश पूरी तरह से अप्रासंगिक है


-3

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

संदेश के रिसीवर पर अपवाद संदेश आश्रितों की सामग्री - तो आपको उस व्यक्ति के जूते में खुद को डालना होगा।

एक सहायता इंजीनियर को त्रुटि के स्रोत को जितनी जल्दी हो सके पहचानने में सक्षम होना चाहिए। एक छोटा वर्णनात्मक स्ट्रिंग प्लस कोई भी डेटा शामिल करें जो समस्या के निवारण में मदद कर सकता है। हमेशा स्टैक ट्रेस शामिल करें - यदि आप कर सकते हैं - यह जानकारी का एकमात्र सच्चा स्रोत होगा।

आपके सिस्टम के सामान्य उपयोगकर्ताओं के लिए त्रुटियों को प्रस्तुत करना त्रुटि के प्रकार पर निर्भर करता है: यदि उपयोगकर्ता समस्या को ठीक कर सकता है, उदाहरण के लिए अलग-अलग इनपुट प्रदान करके, तो एक संक्षिप्त विवरणात्मक संदेश की आवश्यकता है। यदि उपयोगकर्ता समस्या को ठीक नहीं कर सकता है, तो यह बताने के लिए सबसे अच्छा है कि कोई त्रुटि हुई है और समर्थन करने के लिए त्रुटि दर्ज करें / भेजें (ऊपर दिए गए दिशानिर्देशों का उपयोग करके)।

इसके अलावा - एक बड़ा फेंक मत करो "हेलर त्रुटि!" आइकन। यह एक त्रुटि है - यह दुनिया का अंत नहीं है।

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


10
मैं असहमत हूं। जब भाषा एपीआई आपकी सटीक आवश्यकताओं को कवर नहीं करता है तो अपने स्वयं के अपवादों को लागू करने के कई अच्छे कारण हैं। एक कारण यह है कि एक ऐसी विधि जिसमें कई चीजें विफल हो सकती हैं, आप विभिन्न प्रकार के अपवादों के लिए अलग-अलग कैच क्लॉस लिख सकते हैं, जहां आप सटीक समस्या पर प्रतिक्रिया कर सकते हैं। एक और यह है कि आप अपवाद की कई परतों को अलग-अलग कर सकते हैं, जो अमूर्त की अलग-अलग परतों का प्रतिनिधित्व करती हैं, जहाँ सटीक परत जो एक अपवाद से संबंधित है, उसके प्रकार में एन्कोड किया जा सकता है। बस "अपवाद" या "IllegalStateException" और संदेश स्ट्रिंग का उपयोग करने से बहुत मदद नहीं मिलती है।
फेलिक्स डॉम्बेक

1
मैं भी असहमत हूं। अपवाद प्रकारों को कॉलिंग कोड से समझ में आना चाहिए जो इसका उपभोग करेंगे। उदाहरण के लिए, यदि मैं एक रूपरेखा कह रहा हूं और यह आंतरिक रूप से एक FileDoesNotExistException का कारण बनता है, तो यह फ्रेमवर्क के कॉलर के रूप में मेरे लिए कोई मतलब नहीं हो सकता है। इसके बजाय कस्टम अपवाद बनाना और फेंके गए अपवाद को आंतरिक अपवाद के रूप में पारित करना बेहतर हो सकता है।
15
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.