2010-03-10 9 views
5

कहें कि मेरे पास एक विधि में निम्न पंक्ति है:दबाएं या पकड़ें अपवाद जो कभी नहीं हो सकता है?

 String encodedString = URLEncoder.encode(foo, "utf-8"); 

यह विधि UnsupportedEncodingException फेंकता है। जो बेहतर है:

/** @throws UnsupportedEncodingException umm...never 
*/ 
public void myMethod() throws UnsupportedEncodingException { 
    ... 
    String encodedString = URLEncoder.encode(foo, "utf-8"); 
    ... 
} 

(कॉलर को स्वयं को पकड़ने के लिए मजबूर करना) या:

public void myMethod() { 
    try { 
    ... 
    String encodedString = URLEncoder.encode(foo, "utf-8"); 
    ... 
    catch(UnsupportedEncodingException e) { 
     Logger.log("cosmic ray detected!"); 
    } 

} 

या क्या अपवादों को संभालने का एक और शानदार तरीका है जो वास्तव में कभी नहीं हो सकता है?

उत्तर

17

कभी कभी नहीं कहते हैं;)

उदाहरण में ऊपर आप हमेशा अपवाद पकड़ सकते थे तो एक RuntimeException फेंक:

public void myMethod() { 
    try { 
     ... 
     String encodedString = URLEncoder.encode(foo, "utf-8"); 
     ... 
    } catch(UnsupportedEncodingException e) { 
    throw new RuntimeException("This should not be possible",e); 
    } 

} 

इस तरह फोन करने वाले कुछ आप 99.999% यकीन है कि पकड़ने के लिए बाध्य नहीं किया गया कभी नहीं होगा, लेकिन पागल घटना में ऐसा होता है कि आपको अभी भी उस बिंदु पर एक अपवाद बबल मिलता है जहां आप उम्मीद करेंगे कि आप इसे नोटिस करेंगे और जल्दी से यह समझने में सक्षम होंगे कि क्या बदला है और इसे ठीक करें।

HTH

+0

दोनों जवाब महान हैं, लेकिन मैं RuntimeException विचार है, जो बहुत अच्छा है की वजह से इस को स्वीकार कर रहा हूँ। हो सकता है कि एक अवैध स्टाइल अपवाद यहां समझ में आएगा ... – Epaga

+4

एक और संभावना है 'नया AssertionError फेंक दें ("यह नहीं हो सकता", पूर्व) ' –

+0

@StephenC, क्या यह किसी भी तरह से रनटाइम से बेहतर है? – Line

5

तो आप कर सकते हैं काफी गारंटी नहीं है कि अपवाद कभी नहीं हो सकता है, तो यह है कि यह प्रचार देने की बजाय संकीर्ण दायरे में इस दावे को स्थानीय बनाना, क्योंकि अन्य लोगों को एहसास नहीं हो सकता है कि यह मामला है की ओर देखे बिना बेहतर है दस्तावेजों।

यदि किसी विधि को फेंकने के लिए एक विधि घोषित की जाती है, तो वहां परिदृश्य होना चाहिए जहां यह वास्तव में करता है। यदि यह कभी भी करने की गारंटी नहीं देता है, तो throws क्लॉज पूरी तरह से छोड़ना और अपने एपीआई को सरल बनाना बेहतर है।

आपको हमेशा अपने अवशोषण के स्तर (प्रभावी जावा 2 संस्करण, आइटम 61) के लिए उपयुक्त अपवादों को फेंक देना चाहिए। यह घोषणा करते हुए कि आप कुछ फेंक सकते हैं, जब इसकी गारंटी कभी नहीं होती है, तो इस डिजाइन दिशानिर्देश को तोड़ देता है।

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