2012-06-01 34 views
10

के रूप में बेहतर होगा, मुझे पता है कि beenamplediscussion जावा में अनचेक अपवादों के विरुद्ध चेक अपवादों के सापेक्ष गुणों के साथ है, और यह पूरी बहस को फिर से देखने का मेरा इरादा नहीं है।अनचेक अपवाद जो चेक

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

protected Object clone() 
      throws CloneNotSupportedException 

... और फिर तर्क है कि यह एक अनियंत्रित अपवाद के बजाय किया जाना चाहिए था।

यदि एपीआई का उपयोग करने वाला प्रोग्रामर बेहतर नहीं कर सकता है, तो एक अनचेक अपवाद अधिक उपयुक्त होगा। एक अपवाद का एक उदाहरण जो इस परीक्षण में विफल रहता है CloneNotSupportedException है। इसे ऑब्जेक्ट.क्लोन द्वारा फेंक दिया जाता है, जिसे क्लोनेबल (आइटम 11) लागू करने वाली वस्तुओं पर ही लगाया जाना चाहिए। अभ्यास में, पकड़ ब्लॉक लगभग हमेशा एक दावा विफलता का चरित्र है। अपवाद की जांच की गई प्रकृति प्रोग्रामर को कोई लाभ नहीं देती है, लेकिन इसे प्रयासों और जटिल कार्यक्रमों की आवश्यकता होती है।

तब मैंने देखा कि उसके पास बातचीत का एक उदाहरण था, लेकिन मुझे कोई नहीं मिला।

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

संपादित करें: उन लोगों के लिए जिन्होंने इसे गैर-रचनात्मक के रूप में बंद करने के लिए वोट दिया है, मैं यह स्पष्ट करना चाहता हूं कि मैं राय, बहस, तर्क, या विस्तारित चर्चा की तलाश नहीं कर रहा हूं। न ही मैं एक चुनाव ले रहा हूँ। इसके बजाय मैं उन उदाहरणों के संदर्भों की तलाश कर रहा हूं जो लाभों से अधिक लाभों के बारे में स्पष्ट विश्लेषण करते हैं। (इसमें लागू है कि लागतें हैं।) उन्होंने कहा, मुझे इस बात की संदेह है कि इस प्रश्न की प्रकृति इसे संभव बनाती है या नहीं। मुझे लगता है कि जॉन स्कीट ऐसा नहीं कर सकता है, यह असंभव है कि यह किया जा सकता है। तो शायद आप सही हो। अगर आपको चाहिए तो बंद करें।

संपादित करें: हालांकि मैं प्रतिक्रिया से मुक्त हूं, मैं सिर्फ स्वीकृति दर के लिए जॉन को यह पुरस्कार देने जा रहा हूं।

उत्तर

13

यूप, आसानी से: Integer.parseIntNumberFormatException फेंकता है जो अनचेक है।

हालांकि, यदि आप संभावित रूप से खराब डेटा को पार्स कर रहे हैं, तो आपको निश्चित रूप से अपवाद को पकड़ने पर विचार करना चाहिए - आप उस डेटा को अनदेखा कर सकते हैं, या शायद इसकी रिपोर्ट कर सकते हैं और आगे बढ़ सकते हैं। ऐसा नहीं है कि जावा के पास .NET के Int32.TryParse के बराबर है जो आपको आसानी से खराब डेटा को अनदेखा करने देता है। असल में आपको यह जानने की जरूरत है कि संकलक के उत्तेजना के बिना आपको अपवाद को पकड़ने की आवश्यकता है। Grr।

+2

मैं पूरी तरह से सहमत हूं। जब आप कोडिंग कर रहे हों और आप "ज़ोन" दर्ज करते हैं तो यह याद रखना काफी आसान है कि कुछ अपवाद जो पॉप अप करने और चिल्लाते हुए "pwn3d!" या तो क्योंकि आप इसे पकड़ना भूल गए हैं या क्योंकि आपको नहीं पता था कि आपको इसे पकड़ने की आवश्यकता हो सकती है ... – Gamb

+0

आपके त्वरित उत्तर, जॉन के लिए धन्यवाद। आपने एक उदाहरण चुना है जो मुझे परेशान नहीं करता है। मुझे संतुष्ट है कि जावाडॉक में अपवाद का उल्लेख किया गया है, और मैं सराहना करता हूं कि मुझे उन मामलों को चुनने की अनुमति है जिसमें मामलों को संभालने के लिए।क्या आप मानते हैं कि हर उदाहरण एक ही व्यापार के लिए नीचे आ जाएगा? – pohl

+0

@ पोहल: मान लीजिए कि आप * अपनी * विधियों में से एक * Integer.parseInt' को कॉल करें, लेकिन इसे पकड़ने या घोषित करने के लिए भूल जाएं। उस समय, * उस * विधि के किसी भी कॉलर के पास कोई संकेत नहीं है कि क्या हो सकता है। उस स्थिति से अभी भी खुश हैं? –