मैं एक सी # डेवलपर जावा में कभी-कभी कोडिंग कर रहा हूं। क्या कोई सरल शब्दों में समझा सकता है कि जावा में अपवाद क्या हैं और इसकी आवश्यकता क्यों है? सी # में इस शब्द में नहीं आया है।जावा/सी # में चेक अपवाद क्या हैं?
चेक अपवाद अपवाद हैं कि कंपाइलर को किसी भी तरह से संभालने की आवश्यकता होती है।
जावा में, चेक अपवाद Throwable एस हैं जो RuntimeException, Error, या उनके उप-वर्गों में से एक नहीं हैं।
जावा डिज़ाइनर महसूस करते हैं कि कार्यक्रमों को उन अपवादों को संभालने के लिए आवश्यक थे जो उचित रूप से संभवतः थे। एक क्लासिक उदाहरण IOException है। किसी भी समय प्रोग्राम I/O करता है, विफलता की संभावना होती है। डिस्क भर सकती है, फ़ाइल मौजूद नहीं हो सकती है, वहां कोई अनुमति समस्या हो सकती है, आदि
इस प्रकार, जावा को इस प्रकार डिज़ाइन किया गया है कि किसी प्रोग्राम को किसी तरह से अपवाद को व्यवस्थित रूप से संभालना चाहिए। यह एक पकड़ ब्लॉक के साथ हो सकता है, या किसी भी तरह से अपवाद को पुनर्स्थापित कर सकता है।
सी # ने अपवादों की जांच नहीं की है। उन्होंने इस मुद्दे को एप्लिकेशन डेवलपर्स (interview) पर छोड़ने का निर्णय लिया। चेक किए गए अपवाद विवादास्पद हैं क्योंकि वे कोड वर्बोज़ बना सकते हैं, जबकि डेवलपर्स कभी-कभी खाली पकड़ ब्लॉक के साथ उन्हें आसानी से संभालते हैं। इसके अलावा, यह मनमाना हो सकता है कि मानक लाइब्रेरी विधियों ने चेक अपवाद फेंक दिया। उदाहरण के लिए, File.delete क्यों नहीं (एक नया जावा 7 एपीआई अलग-अलग करता है) IOException फेंक दें?
एक और चिंता हेजल्सबर्ग ने उस साक्षात्कार में उल्लेख किया है संस्करण। throw खंड में एक चेक अपवाद जोड़ना उस विधि का उपयोग करके सभी कोड को संशोधित और पुन: संकलित करने के लिए मजबूर करता है।
अद्भुत स्पष्टीकरण। धन्यवाद! – blitzkriegz
'थ्रो क्लॉज में एक चेक अपवाद जोड़ना उस विधि का उपयोग करके सभी कोड को संशोधित और पुन: संकलित करने के लिए मजबूर करता है' - इसलिए आपके पास अनचेक अपवाद हैं। खैर, अगर आपको लगता है कि 'कुछ परिस्थितियों में विफल हो जाएंगे' यह है कि आप अपने एपीआई का वर्णन कैसे करना चाहते हैं। प्रत्येक अपवाद एक विधि के सार्वजनिक इंटरफ़ेस का हिस्सा है, बाद में जोड़ना यह कहने जैसा है "ओह और अब से उस int पैरामीटर पर एक पूरी तरह से अर्थपूर्ण अर्थ होगा - लेकिन चिंता न करें, यह अभी भी बाइनरी संगत है!" – Voo
@Voo, साक्षात्कार के विशेष रूप से [इस भाग] (http://www.artima.com/intv/handcuffs2.html) में इस पर चर्चा की गई है। हेजल्सबर्ग का तर्क है कि तत्काल कॉलिंग कोड द्वारा हर अपवाद को वास्तव में संभालने की आवश्यकता नहीं है। उनका कहना है कि कुछ मुख्य संदेश हैंडलर द्वारा सबसे अच्छे तरीके से संभाले जाते हैं, भले ही वह मुख्य हैंडलर नए अपवाद के विशिष्ट ज्ञान के साथ नहीं लिखा गया हो। –
चेक अपवाद अपवाद हैं जिन्हें किसी भी "खपत" वर्ग की आवश्यकता होती है जो उस कोड को स्पष्ट रूप से जांचता है (और आशा करता है) अपवाद।
उदाहरण के लिए, यदि ऐप्पल क्लास में ईट() विधि है जिसमें वर्मफाउंड के चेक अपवाद शामिल हैं तो उस विधि को कॉल करने वाले किसी भी कोड को उस अपवाद के लिए स्पष्ट रूप से पकड़ने की आवश्यकता होगी।
एक साइड नोट के रूप में, यह जावा की विशेषता है और सी # नहीं है।
(बिंदु जब सी # बनाया गया था पर, जांचे हुए अपवादों के पेशेवरों नहीं तो स्पष्ट सी # टीम की नजर में तो वे शामिल नहीं थे थे।)
जावा में, एक अपवाद जाँच (जैसा मैथ्यू फ्लैंचन सही ढंग से इंगित करता है) एक अपवाद है कि संकलक को आपको संभालने की आवश्यकता होती है। । या जब एक पूर्णांक पार्स करने जैसे NumberFormatException, IOException जब किसी फ़ाइल के लिए लिख
हालांकि, कुछ अपवाद से फेंका जा सकता है - ये अपवाद है कि समारोह परिभाषा पर घोषित किया गया है (उदाहरण के लिए function bob() throws ImNotBobException { ... } कहना है कि कि समारोह बुला कि अपवाद फेंक कर सकते हैं अज्ञात या अप्रत्याशित स्थान जो हर स्तर पर संभालने के लिए बस अव्यवहारिक होते हैं, इसलिए कंपाइलर को इन्हें संभालने की आवश्यकता नहीं होती है। ये अनचेक अपवाद हैं। उन्हें विभिन्न स्थानों से फेंक दिया जा सकता है जो उन्हें फेंकने की घोषणा नहीं करते हैं (अक्सर प्रयास करके किसी ऑब्जेक्ट पर एक विधि को कॉल करने के लिए जब उस ऑब्जेक्ट को अभी तक प्रारंभ नहीं किया गया है, यानी शून्य है - इसका परिणाम NullPointerException होगा।)
उम्मीद है कि यह मदद करता है।
चेक अपवाद एक त्रुटि है। कोई अन्य स्पष्टीकरण गलत है। – earizon
(कुछ साल बाद, गूगल विमान सेवाओं के माध्यम यहां आने वाले लोगों के लिए)
चेक-इन अपवाद जावा भाषा के डिजाइन में एक गलती थी। अवधि। जब भी आपको एक चेक अपवाद मिलता है तो उन्हें अनचेक अपवाद (शायद एक रनटाइम अपवाद) में लपेटें।
दुर्भाग्यवश, मार्केटिंग मुद्दों के कारण, पहला सूर्य, फिर ओरेकल अपनी गलती को खुले तौर पर पहचानने में असमर्थ थे।
उस समय जब जावा बनाया गया था अपवादों का संचालन स्पष्ट नहीं था। जावा डिजाइनरों ने मूर्खता से सोचा कि डेवलपर्स को संकलन समय पर अपवादों की जांच करने के लिए मजबूर करना एक अच्छा विचार था। हालांकि यह सहजता से सही दिखता है, यह "गोटो" के उपयोग के समान एक विरोधी पैटर्न बन गया है। यह अभ्यास में कभी काम नहीं करता और बहुत सारी समस्याओं का कारण बनता है। अपवादों को "मुख्य-लूप" या "नियंत्रक" में संभाला जाना चाहिए, अन्यथा, क्या वे त्रुटि को बढ़ाने वाले फ़ंक्शन के अंदर संभालने में सक्षम थे, वे अपवाद नहीं होंगे, लेकिन एक चिंतित त्रुटि जिसे समर्थित होना चाहिए सामान्य एपीआई वापसी मूल्य। एक अपवाद, अपनी प्रकृति से, कुछ विचार नहीं किया जाता है और यह कोड के सामान्य प्रवाह निष्पादन की अनुमति नहीं देता है।
उदाहरण के लिए नोटिस कि वसंत, एंटरप्राइज़ ऐप विकास के लिए "मानक" जावा ढांचा, अनचेक अपवादों में चेक-अपवादों को लपेटने के लिए बस सीमित है।
सी # इस मुद्दे को ठीक किया गया। वास्तव में, सी # में यह समस्या नहीं है।
क्या आपका मतलब "अपवाद चेक किया गया" था? यदि आपने किया तो कृपया प्रश्न संपादित करें। – dasblinkenlight
@dasblinkenlight, इसे अपवाद टैग किया गया था, इसलिए मैंने इसे संपादित किया। –
धन्यवाद! उस टाइपो के बारे में खेद है। – blitzkriegz