9

मैंने अध्ययन किया है कि: एक अनचेक अपवाद के साथ, हालांकि, कंपाइलर क्लाइंट प्रोग्रामर को अपवाद पकड़ने या इसे फेंकने वाले खंड में घोषित करने के लिए मजबूर नहीं करता है। वास्तव में, क्लाइंट प्रोग्रामर यह भी नहीं जानते कि अपवाद फेंक दिया जा सकता है। उदाहरण के लिए, StringIndexOutOfBoundsException स्ट्रिंग की charAt() विधि द्वारा फेंक दिया गया।चेक किए गए बनाम अनचेक अपवाद

इसका क्या अर्थ है?

उस कोड के अनुसार कोड, में कोड को पकड़ने की आवश्यकता नहीं है, लेकिन मैंने कोड पकड़ने की कोशिश में कोड डालने के लिए कंपाइलर बलों को देखा है।

मैं बहुत उलझन में हूं कि वे वास्तव में क्या हैं?

उत्तर

4

आपका प्रश्न वास्तव में क्या है? कंपाइलर्स को अनचेक अपवादों को आजमाने/पकड़ने के लिए आपको लागू नहीं करना चाहिए (जो नहीं होगा), जो वास्तव में उनके खिलाफ होगा।

सामान्य विचार यह है कि चेक अपवाद कुछ ऐसा है जो आप देख सकते हैं लेकिन आपके नियंत्रण से बाहर इनपुट पर आधारित हो सकता है और आपको इसका सामना करना पड़ता है। अनचेक अपवाद आमतौर पर आपके प्रोग्राम में बग का प्रतिनिधित्व करेंगे।

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

16

अनचेक अपवाद वे हैं जो RuntimeException कक्षा का विस्तार करते हैं। कंपाइलर आपको इस तरह के अपवाद को पकड़ने के लिए मजबूर नहीं करेगा या आपको throws कीवर्ड का उपयोग करके विधि में घोषित करने के लिए मजबूर नहीं करेगा। अन्य सभी अपवाद प्रकार (जो RuntimeException का विस्तार नहीं करते हैं) चेक किए जाते हैं और इसलिए उन्हें फेंकने और/या पकड़ने के लिए घोषित किया जाना चाहिए।

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

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

+10

'त्रुटि' से विस्तारित अपवाद भी अनचेक किए गए हैं। – stolsvik

3

यह है, क्योंकि

  1. अनियंत्रित अपवाद प्रोग्रामर की गलती का परिणाम नहीं हैं। इसके बजाय वे गंभीर परिणाम हैं जहां हम (प्रोग्रामर) से इसके साथ बहुत कुछ करने की उम्मीद नहीं है।
  2. चेक किए गए अपवाद के मामले में, यह प्रोग्रामर की गलती & अक्सर की वजह से उत्पन्न एक अपवाद प्रोग्रामर से ही हल किया जा सकता है।

चेक निम्न लिंक:

Why RunTime Exceptions are unchecked ?
Checked vs Unchecked Exception ?

+5

यह दूसरी तरफ है। जब एक उत्साह प्रोग्रामर गलती है, तो इसे अनचेक किया जाना चाहिए। यह ठीक करने के बजाए एक बग को पकड़ने के बजाय व्यर्थ है। यदि यह प्रोग्रामर गलती नहीं है लेकिन बाहरी पैरामीटर के कारण होता है (उदाहरण के लिए नेटवर्क त्रुटि) इसे जांचना चाहिए। – Tomas

+2

** भ्रामक! ** क्या कोई संपादन करने के लिए पर्याप्त प्रतिनिधि के साथ कोई इसे ठीक कर सकता है? – ADTC

+0

मैंने एक सुधार प्रस्तुत किया है और यह सहकर्मी समीक्षा का इंतजार कर रहा है। – PaulrBear

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

चेक अपवादों की उपयोगिता का एक स्पष्ट उदाहरण एपीआई कॉल का उपयोग है जो उन संसाधनों तक पहुंच/निर्भर करता है जो हमेशा मौजूद नहीं हो सकते हैं - मूल रूप से java.io, दूसरों के बीच। चूंकि इस प्रकार की आबादी की स्थिति अनुमानित हो सकती है और आमतौर पर एक बुद्धिमान त्रुटि संदेश प्रतिक्रिया के साथ पकड़ा जा सकता है), यह लागू करना कि प्रोग्रामर पर अपवाद प्रबंधन का न्यूनतम बोझ अच्छा अभ्यास है। – theRiley

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^