जावा में अनियंत्रित अपवादों की जाँच की गई समझ

Question

" प्रभावी जावा " में जोशुआ बलोच ने कहा कि

प्रोग्रामिंग की त्रुटियों के लिए पुनर्प्राप्त करने योग्य शर्तों और रनटाइम अपवादों के लिए जाँच किए गए अपवादों का उपयोग करें (2 संस्करण में आइटम 58)

आइए देखें कि क्या मैं इसे सही ढंग से समझता हूं।

यहाँ एक जाँच अपवाद की मेरी समझ है:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. क्या उपरोक्त जाँच को अपवाद माना गया है?

2. क्या RuntimeException एक अनियंत्रित अपवाद है?

यहाँ एक अनियंत्रित अपवाद की मेरी समझ है:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. अब, उपरोक्त कोड भी एक जाँच अपवाद नहीं हो सकता है? मैं इस तरह की स्थिति को ठीक करने की कोशिश कर सकता हूं? क्या मैं? (नोट: मेरा तीसरा प्रश्न catchउपरोक्त है)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. लोग ऐसा क्यों करते हैं?

public void someMethod throws Exception{

}

वे अपवाद बुलबुले को क्यों करते हैं? क्या त्रुटि को जल्द से जल्द बेहतर नहीं करना है? बुलबुला क्यों?

6. क्या मुझे अपवाद का उपयोग करना चाहिए या अपवाद का उपयोग करना चाहिए?

नीचे मेरी रीडिंग हैं

जावा में, मुझे एक चेक अपवाद कब बनाना चाहिए, और यह एक रनटाइम अपवाद कब होना चाहिए?

कब चुने और अनियंत्रित अपवादों का चयन करें

Comments

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

— एरिक रॉबर्टसन

और भी भ्रम जोड़ने के लिए। बहुत से लोग ~ 10 साल पहले चेक किए गए अपवादों की वकालत कर रहे थे, लेकिन अब दृश्य अधिक है और "चेक किए गए अपवाद बुरे हैं" की ओर बढ़ रहे हैं। (हालांकि मैं इस पर सहमत नहीं हूं)

— काज

यह केवल एक अपवाद को संभालने के लिए उपयोगी है जब आपके पास इसके साथ कुछ उपयोगी हो, अन्यथा आपको कॉलर को इसे संभालने देना चाहिए। इसे लॉग इन करना और ऐसा करने का नाटक करना आमतौर पर उपयोगी नहीं होता है। बस इसे फिर से फेंकना व्यर्थ है। एक RuntimeException में रैप करना कुछ सोच के जितना उपयोगी नहीं है, यह सिर्फ कंपाइलर को आपकी मदद करना बंद कर देता है। (

— आईएमएचओ

हमें जाँच / अनियंत्रित अपवादों के व्यापक रूप से भ्रामक शब्दों का उपयोग करना बंद कर देना चाहिए । वे बुलाया जाना चाहिए जांच अनिवार्य बनाम जांच नहीं आदेशित अपवाद नहीं।

— धन्य गीक

मैंने यह भी सोचा है कि abt ur 5th point public void method_name फेंकता है Exception {} कुछ लोग ऐसा क्यों करते हैं?

— मेवेद

Answer 1

बहुत से लोग कहते हैं कि चेक किए गए अपवाद (यानी ये कि आपको स्पष्ट रूप से पकड़ना चाहिए या फिर से फेंकना चाहिए) का उपयोग बिल्कुल भी नहीं किया जाना चाहिए। वे उदाहरण के लिए C # में समाप्त हो गए थे, और अधिकांश भाषाओं में वे नहीं थे। तो आप हमेशा RuntimeException(अनियंत्रित अपवाद) का उपवर्ग फेंक सकते हैं

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

यहाँ विषय पर मेरा विस्तारित विचार है ।

विशेष प्रश्नों के लिए:

1. क्या NumberFormatExceptionविचार एक अपवाद है?
   सं। NumberFormatExceptionअनियंत्रित है (= उपवर्ग है RuntimeException)। क्यों? मुझे नहीं पता। (लेकिन एक तरीका होना चाहिए था isValidInteger(..))

2. है RuntimeException एक अनियंत्रित अपवाद है?
   हाँ बिल्कुल।

3. मुझे यहां क्या करना चाहिए?
   यह निर्भर करता है कि यह कोड कहां है और आप क्या करना चाहते हैं। अगर यह यूआई परत में है - इसे पकड़ें और चेतावनी दिखाएं; अगर यह सेवा की परत में है - इसे बिलकुल न पकड़ें - इसे बुलबुले बनने दें। बस अपवाद निगल नहीं है। यदि अधिकांश मामलों में अपवाद होता है, तो आपको इनमें से एक को चुनना चाहिए:

   • इसे लॉग इन करें और वापस लौटें
   • इसे वापस लाएं (इसे विधि द्वारा फेंके जाने की घोषणा करें)
   • कंस्ट्रक्टर में वर्तमान एक को पारित करके एक नया अपवाद बनाएं

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

5. लोग Exceptionथ्रो क्लॉज में क्लास क्यों जोड़ते हैं ?
   सबसे अधिक बार क्योंकि लोग यह सोचने के लिए आलसी होते हैं कि क्या पकड़ना है और क्या पुनर्विचार करना है। फेंकना Exceptionएक बुरा अभ्यास है और इससे बचना चाहिए।

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

Comments

अपवाद को फेंकने के बारे में, यह हमेशा नहीं होता है क्योंकि लोग आलसी होते हैं, यह भी सामान्य है कि जब आप रूपरेखा लागू करते हैं, तो रूपरेखा के उपयोगकर्ता किसी भी अपवाद को फेंकने में सक्षम हों। आप उदाहरण के तौर पर JSE

— काज

@ काज - हां, ऐसी सामान्य चीजें जैसे कि कॉल करने योग्य, इंटरसेप्टर और पसंद विशेष मामले हैं। लेकिन ज्यादातर मामलों में ऐसा इसलिए होता है क्योंकि लोग आलसी होते हैं :)

— Bozho

पुन :: 3.1 "इसे लॉग इन करें और वापस लौटें" इतना विवेकपूर्ण ढंग से करें। यह खाने या छिपने और अपवाद के बहुत करीब है। मैं ऐसा कुछ करता हूं जो किसी समस्या का संकेत नहीं देता है, जो वास्तव में असाधारण नहीं है। लॉग में बाढ़ आ जाती है और इसे आसानी से अनदेखा कर दिया जाता है।

— क्रिस

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

— एड्रियनोस

@adrianos "... आप किसी को यह सोचने के लिए मजबूर नहीं कर सकते कि क्या वे नहीं चाहते हैं ...." इस विचारधारा के साथ हम संकलन त्रुटियों को भी दूर कर सकते हैं .... मैं वास्तव में आपको लक्षित नहीं कर रहा हूं, मैंने यह सुना है तर्क समय और फिर से और अभी भी इसे विफलता के रूप में चेक किए गए अपवादों को लेबल करने के लिए सबसे खराब संभव स्पष्टीकरण होना चाहिए। एक साइड नोट के रूप में, मैंने ऐसी भाषा से पहले देखा है जहां संकलन (और रनटाइम त्रुटियों के साथ-साथ वास्तव में) को प्रभावी रूप से desing द्वारा असंभव बना दिया गया था। उस सड़क के कारण कुछ बहुत ही अंधेरी जगह थी।

— न्यूटोपियन

Answer 2

चाहे कुछ "चेक किया गया अपवाद" हो, इससे कोई लेना-देना नहीं है कि आप इसे पकड़ते हैं या आप कैच ब्लॉक में क्या करते हैं। यह अपवाद वर्गों की संपत्ति है। कुछ भी की एक उपवर्ग है कि Exception को छोड़कर के लिए RuntimeExceptionऔर उसके उपवर्गों एक जाँच अपवाद नहीं है।

जावा कंपाइलर आपको अपवादों को पकड़ने के लिए बाध्य करता है या विधि हस्ताक्षर में उन्हें घोषित करता है। यह कार्यक्रम की सुरक्षा में सुधार करने वाला था, लेकिन बहुमत की राय से लगता है कि यह डिजाइन की समस्याओं के लायक नहीं है जो इसे बनाता है।

वे अपवाद बुलबुले को क्यों करते हैं? इस त्रुटि को जल्द ही बेहतर संभाल नहीं है? बुलबुला क्यों?

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

Comments

धन्यवाद! मैं कभी-कभी अपने तरीकों से अपवादों को बाहर फेंक देता हूं क्योंकि क्रेप आउट सिद्धांत में बकवास है। मैं अपनी टीम के डेवलपर्स में से एक को अमान्य xpath अभिव्यक्ति में शामिल करना चाहता हूं ताकि अपवाद से निपटने के लिए उन तक पहुंच सके। अप्रत्याशित घटना में वे एक अपवाद को पकड़ते हैं और कुछ भी नहीं करते हैं जो वे कोड समीक्षा में इसके बारे में सुनेंगे।

— jeremyjjbrown

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

— बार्टज़िला

@JonasEicher: मूल रूप से, अपवादों का एक मुख्य लाभ यह है कि वे आपको यह चुनने की अनुमति देते हैं कि कॉल स्टैक में आप त्रुटियों को कैसे संभालना चाहते हैं, जो अक्सर उच्च स्तर पर होता है, जबकि परतों को पूरी तरह से त्रुटि से निपटने कलाकृतियों के बीच मुक्त रखना। चेक किए गए अपवाद बिल्कुल उस लाभ को नष्ट कर देते हैं। एक अन्य समस्या यह है कि जाँच की गई / अनियंत्रित को अपवाद वर्ग से जोड़ा जाता है जो अपवादों के एक वैचारिक वर्गीकरण का प्रतिनिधित्व करता है - दो पहलुओं को मिलाकर जो कि आवश्यक रूप से संबंधित नहीं हैं।

— माइकल बोर्गवर्ड

"लेकिन बहुमत की राय से लगता है कि यह डिजाइन समस्याओं के लायक नहीं है जो इसे बनाता है।" - प्रशस्ति पत्र कृपया?

— केरविन

@ क्वार्ट्जिला हां। पूर्णता के लिए, जैसा कि javadoc के लिए Throwableकहता है: "थ्रोएबल और थ्रोबल के किसी भी उपवर्ग जो कि रनटाइम एक्सेप्शन या त्रुटि का एक उप-वर्ग भी नहीं है, चेक अपवाद के रूप में माना जाता है"

— बार्ट वैन ह्युकेलेलो

Answer 3

1. क्या उपरोक्त को एक अपवाद माना गया है? कोई तथ्य यह नहीं है कि आप एक अपवाद को संभाल रहे हैं Checked Exceptionअगर यह एक ऐसा नहीं है RuntimeException।

2. है RuntimeExceptionएक unchecked exception? हाँ

Checked Exceptionsकर रहे हैं subclassesके java.lang.Exception Unchecked Exceptionsहैं subclassesकीjava.lang.RuntimeException

चेक किए गए अपवादों को फेंकने वाले कॉलों को विधि के कॉलर में एक कोशिश {} ब्लॉक या ऊपर के स्तर में संभाला जाना चाहिए। उस स्थिति में वर्तमान विधि को यह घोषित करना चाहिए कि उसने फेंके गए अपवादों को फेंक दिया ताकि कॉल करने वाले अपवाद को संभालने के लिए उचित व्यवस्था कर सकें।

उम्मीद है की यह मदद करेगा।

प्रश्न: क्या मुझे अपवाद का उपयोग करना चाहिए या अपवाद का उपयोग करना चाहिए?

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

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

इसके बजाय निम्नलिखित करें:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

मूल मूल कारण खाने से ठीक होने से परे वास्तविक कारण होता है, उत्पादन समर्थन टीमों के लिए एक बुरा सपना है, जहां उन्हें आवेदन लॉग और त्रुटि संदेश दिए जाते हैं। हालांकि बाद वाला एक बेहतर डिजाइन है, लेकिन कई लोग इसका उपयोग अक्सर नहीं करते हैं क्योंकि डेवलपर्स सिर्फ कॉल करने वाले को अंतर्निहित संदेश देने में विफल होते हैं। तो एक ठोस नोट करें: Always pass on the actual exceptionकिसी भी एप्लिकेशन विशिष्ट अपवाद में लिपटे हुए हैं या नहीं।

कोशिश-पकड़ने पर RuntimeExceptions

RuntimeExceptionसामान्य नियम के रूप में s को पकड़ने की कोशिश नहीं की जानी चाहिए। वे आम तौर पर एक प्रोग्रामिंग त्रुटि का संकेत देते हैं और उन्हें अकेला छोड़ दिया जाना चाहिए। इसके बजाय प्रोग्रामर को कुछ कोड लागू करने से पहले त्रुटि की स्थिति की जांच करनी चाहिए, जिसके परिणामस्वरूप हो सकता है RuntimeException। पूर्व के लिए:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

यह एक खराब प्रोग्रामिंग प्रैक्टिस है। इसके बजाय एक शून्य-जांच की जानी चाहिए थी -

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

लेकिन ऐसे समय होते हैं जब इस तरह की त्रुटि जाँच महंगी होती है जैसे कि संख्या स्वरूपण, इस पर विचार करें -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

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

इसलिए NullPointerExceptionऔर NumberFormatExceptionदोनों RuntimeExceptionsको पकड़ना NullPointerExceptionचाहिए , जब तक NumberFormatExceptionकि त्रुटि प्रवण कोड के संभावित परिचय से बचने के लिए मैं स्पष्ट रूप से पकड़ने की सलाह देता हूं, एक सुंदर अशक्त जांच के साथ बदल देना चाहिए ।

Comments

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

— थांग फाम

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

— डी-लाइव

आपका बहुत बहुत धन्यवाद। क्या यह संभव होगा कि आप मुझे इसकी सामग्री दिखा सकें LoginFailureException(sqle)?

— थांग फाम

मेरे पास उस सामान के लिए कोई कोड नहीं है, मैंने सिर्फ नाम आदि को पकाया है। अगर आपको java.lang.Exception दिखाई देती है, तो इसमें 4 निर्माता हैं जिनमें से दो ने java.lang.Throwable स्वीकार किया है। के टुकड़े में मैं ऊपर मान लिया LoginFailureExceptionफैली Exceptionऔर एक निर्माता वाणीpublic LoginFailureException(Throwable cause) { super(cause) }

— डी-लाइव

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

— हुसैन

Answer 4

1 है। यदि आप अपवाद के बारे में अनिश्चित हैं, तो API की जाँच करें:

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

२। हां, और हर अपवाद जो इसे विस्तारित करता है।

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

४। FileNotFoundException है पहले ही एक जाँच अपवाद है।

५। यदि यह उम्मीद है कि विधि बुला रही हैsomeMethod अपवाद को पकड़ने के लिए , बाद को फेंक दिया जा सकता है। यह सिर्फ "गेंद को पास करता है"। यदि आप इसे अपने निजी तरीकों से फेंकना चाहते हैं, तो इसका उपयोग इसका एक उदाहरण होगा, और इसके बजाय अपनी सार्वजनिक पद्धति में अपवाद को संभालना होगा।

एक अच्छा पठन ओरेकल डॉक्टर ही है: http://download.oracle.com/javase/tutorial/essential/exception/tuntime.html

डिजाइनरों ने सभी अनिर्दिष्ट चेक अपवादों को निर्दिष्ट करने के लिए एक विधि को बाध्य करने का निर्णय क्यों लिया जो इसके दायरे में फेंके जा सकते हैं? किसी भी अपवाद को एक विधि द्वारा फेंका जा सकता है जो विधि के सार्वजनिक प्रोग्रामिंग इंटरफ़ेस का हिस्सा है। जो लोग एक विधि कहते हैं उन्हें अपवादों के बारे में पता होना चाहिए कि एक विधि फेंक सकती है ताकि वे तय कर सकें कि उनके बारे में क्या करना है। ये अपवाद उस पद्धति के प्रोग्रामिंग इंटरफ़ेस का एक हिस्सा हैं जितना कि इसके पैरामीटर और रिटर्न वैल्यू।

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

जावा लैंग्वेज स्पेसिफिकेशन में एक महत्वपूर्ण जानकारी भी है :

थ्रो क्लॉज में नामित चेक अपवाद क्लासेस मेथोडर या कंस्ट्रक्टर के कार्यान्वयनकर्ता और उपयोगकर्ता के बीच अनुबंध का हिस्सा हैं ।

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

Comments

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

— थांग फाम

@ हेरी मैं अपने से अधिक ज्ञान वाले लोगों को जवाब देने के लिए

— कहूंगा

Answer 5

1) नहीं, एक NumberFormatException एक अनियंत्रित अपवाद है। भले ही आपने इसे पकड़ लिया हो (आपको इसकी आवश्यकता नहीं है) क्योंकि यह अनियंत्रित है। ऐसा इसलिए है क्योंकि यह एक उपवर्ग है IllegalArgumentExceptionजिसका एक उपवर्ग है RuntimeException।

2) RuntimeExceptionसभी अनियंत्रित अपवादों की जड़ है। हर उपवर्ग RuntimeExceptionअनियंत्रित है। सभी अन्य अपवाद और Throwableत्रुटियों के अलावा जाँच की जाती है (जो कि अंतर्गत आती हैThrowable )।

3/4) आप उपयोगकर्ता को सचेत कर सकते हैं कि वे एक गैर-मौजूद फ़ाइल उठाए और एक नया मांगें। या उपयोगकर्ता को सूचित करना छोड़ दें कि उन्होंने कुछ अमान्य दर्ज किया है।

5) फेंकना और पकड़ना 'Exception' बुरा व्यवहार है। लेकिन आम तौर पर, आप अन्य अपवादों को फेंक सकते हैं ताकि कॉलर तय कर सके कि इससे कैसे निपटना है। उदाहरण के लिए, यदि आपने कुछ फ़ाइल इनपुट पढ़ने के लिए एक लाइब्रेरी लिखी है और आपका तरीका एक गैर-मौजूद फ़ाइल है, तो आपको पता नहीं है कि इसे कैसे संभालना है। क्या कॉलर फिर से पूछना चाहता है या छोड़ना चाहता है? इसलिए आप एक्सेप्शन को चेन को वापस कॉलर पर फेंक देते हैं।

कई मामलों में, ऐसा unchecked Exceptionहोता है क्योंकि प्रोग्रामर ने इनपुट्स का सत्यापन नहीं किया है ( NumberFormatExceptionआपके पहले प्रश्न के मामले में )। यही कारण है कि इसका विकल्प उन्हें पकड़ने के लिए है, क्योंकि उन अपवादों को उत्पन्न करने से बचने के लिए अधिक सुरुचिपूर्ण तरीके हैं।

Comments

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

— थांग फाम

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

— नॉटकसटा

Answer 6

जाँच की गई - होने की संभावना है। संकलित समय में जाँच की।

उदा .. फाइलऑपरेशन

UnChecked - खराब डेटा के कारण। रन समय में जांच की गई।

उदाहरण के लिए ..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

यहां अपवाद खराब डेटा के कारण है और किसी भी तरह से इसे संकलन समय के दौरान निर्धारित नहीं किया जा सकता है।

Answer 7

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

अनियंत्रित अपवाद विशुद्ध रूप से प्रोग्रामेटिक त्रुटियां, गलत गणना, अशक्त डेटा या यहां तक ​​कि व्यावसायिक तर्क में विफलताओं के कारण रनिंग अपवाद हो सकते हैं। कोड में अनियंत्रित अपवादों को संभालने / पकड़ने के लिए इसका बिल्कुल ठीक है।

Http://coder2design.com/java-interview-questions/ से लिया गया स्पष्टीकरण

Answer 8

जावा ट्यूटोरियल ट्रेल लेख, " अनियंत्रित अपवाद - विवाद " (इस पोस्ट पर सभी प्राथमिक प्राप्त करने के लिए खेद है - लेकिन, हे, मूल बातें कभी-कभी सबसे अच्छी होती हैं) द्वारा अनियंत्रित और जाँच किए गए अपवादों के बीच अंतर का मेरा पूर्ण पसंदीदा विवरण प्रदान किया गया है :

यहां नीचे पंक्ति दिशानिर्देश है: यदि किसी ग्राहक से किसी अपवाद से उबरने की अपेक्षा की जा सकती है, तो उसे एक अपवाद बनाएं। यदि कोई क्लाइंट अपवाद से पुनर्प्राप्त करने के लिए कुछ नहीं कर सकता है, तो इसे अनियंत्रित अपवाद बनाएं

"फेंकने के लिए किस प्रकार का अपवाद" का अर्थ शब्दार्थ है (कुछ हद तक) और उपरोक्त उद्धरण प्रदान करता है और उत्कृष्ट दिशानिर्देश (इसलिए, मैं अभी भी इस धारणा से उड़ा रहा हूं कि सी # को जाँच अपवादों से छुटकारा मिल गया - विशेष रूप से लिस्कोव के लिए। उनकी उपयोगिता)।

बाकी तो तार्किक हो जाता है: किस अपवाद के कारण कंपाइलर मुझे जवाब देने की उम्मीद करता है, स्पष्ट रूप से? जिनसे आप क्लाइंट के ठीक होने की उम्मीद करते हैं।

Answer 9

अंतिम प्रश्न का उत्तर देने के लिए (दूसरों को अच्छी तरह से उत्तर दिया गया प्रतीत होता है), "क्या मुझे सटीक अपवाद को बुलबुला करना चाहिए या अपवाद का उपयोग करके इसे मुखौटा करना चाहिए?"

मैं मान रहा हूं कि आप कुछ इस तरह हैं:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

नहीं, हमेशा सबसे सटीक अपवाद को संभव घोषित करें , या ऐसी सूची। जिन अपवादों को आप अपना तरीका घोषित करते हैं, उन्हें फेंकने में सक्षम अपनी विधि और कॉलर के बीच अनुबंध का एक हिस्सा है। फेंकने का "FileNotFoundException"मतलब है कि यह संभव है कि फ़ाइल नाम मान्य नहीं है और फ़ाइल नहीं मिलेगी; फोन करने वाले को समझदारी से संभालना होगा। फेंकने का Exceptionअर्थ है "अरे, श * टी होता है। डील।" जो बहुत गरीब है API।

पहले लेख पर टिप्पणियों में कुछ उदाहरण हैं जहां "फेंकता Exception" एक वैध और उचित घोषणा है, लेकिन normalआप कभी भी लिखेंगे सबसे " " कोड के लिए ऐसा नहीं है ।

Comments

सटीक रूप से, अपने सॉफ़्टवेयर का उपयोग करने वाले व्यक्ति की सहायता करने के साथ-साथ अपने कोड दस्तावेज़ के अपने चेक अपवाद घोषणा भाग को भी बनाएं।

— साल्वाडोर वालेंसिया

Answer 10

रनटाइम अपवाद : रनटाइम अपवाद को अनियंत्रित अपवाद के रूप में संदर्भित किया जाता है। अन्य सभी अपवादों की जाँच की जाती है, और वे java.lang.RuntimeException से प्राप्त नहीं होते हैं।

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

जावा एपीआई थ्रो अपवादों में तरीकों की एक संख्या है, इसलिए आप अक्सर अपवाद हैंडलर लिखेंगे जो आपके द्वारा लिखे गए तरीकों से उत्पन्न अपवादों के साथ सामना करेंगे।

Answer 11

वे अपवाद बुलबुले को क्यों करते हैं? क्या त्रुटि को जल्द से जल्द बेहतर नहीं करना है? बुलबुला क्यों?

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

नोट: त्रुटि प्रकार क्या हुआ है, इसका स्पष्ट विवरण देने के लिए हम अपनी स्वयं की अपवाद वस्तु बना सकते हैं और इसे ग्राहक को फेंक सकते हैं।

Comments

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

— साल्वाडोर वालेंसिया

Answer 12

मुझे लगता है कि चेक किए गए अपवाद डेवलपर के लिए एक अच्छा अनुस्मारक हैं जो बाहरी पुस्तकालय का उपयोग करता है कि असाधारण परिस्थितियों में उस पुस्तकालय से कोड के साथ चीजें गलत हो सकती हैं।

चेक किए गए बनाम अनियंत्रित अपवादों के बारे में यहाँ और पढ़ें http://learnjava.today/2015/11/checked-vs-unchecked-exception/

Answer 13

मैं केवल जाँच किए गए अपवादों का उपयोग नहीं करने के लिए कुछ तर्क जोड़ना चाहता हूं। यह एक पूर्ण उत्तर नहीं है, लेकिन मुझे लगता है कि यह आपके प्रश्न का उत्तर देता है, और कई अन्य उत्तरों का अनुपालन करता है।

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

मैं आपको एक उदाहरण दिखाता हूं।

चलो इस तरह एक अच्छा और साफ इंटरफ़ेस है

public interface IFoo {
    public void foo();
}

अब हम विधि के कई कार्यान्वयन लिख सकते हैं foo(), जैसे ये

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

क्लास फू पूरी तरह से ठीक है। अब क्लास बार में पहला प्रयास करते हैं

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

यह क्लास बार संकलित नहीं होगा। जैसा कि InterruptedException एक चेक किया गया अपवाद है, आपको या तो इसे कैप्चर करना होगा (विधि foo () के अंदर ट्राइ-कैच के साथ) या घोषित करें कि आप इसे फेंक रहे हैं ( throws InterruptedExceptionविधि हस्ताक्षर में जोड़कर )। जैसा कि मैं इस अपवाद को यहाँ कैप्चर नहीं करना चाहता (मैं चाहता हूं कि यह ऊपर की ओर प्रचारित हो, ताकि मैं इसे कहीं और ठीक से निपटा सकूं), चलो हस्ताक्षर को बदल दें।

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

इस वर्ग बार या तो संकलन नहीं होगा! बार के विधि फू () उनके हस्ताक्षर अलग होने के बाद से IFoo की विधि फू () को ओवरराइड नहीं करते हैं। मैं @ ऑवरराइड एनोटेशन को निकाल सकता था, लेकिन मैं इंटरफ़ेस आईएफयू के खिलाफ प्रोग्राम करना चाहता हूं जैसे IFoo foo;और बाद में यह तय करना था कि मैं किस कार्यान्वयन का उपयोग करना चाहता हूं, जैसे foo = new Bar();। यदि बार का विधि फू () IFoo की विधि फू को ओवरराइड नहीं करता है, जब मैं करता हूं तो foo.foo();यह बार के कार्यान्वयन को फू () नहीं कहेगा।

बार के public void foo() throws InterruptedExceptionओवरराइड करने के लिए IFoo के public void foo()I MUST throws InterruptedExceptionको IFoo के विधि हस्ताक्षर में जोड़ना होगा। हालाँकि, यह मेरे फू वर्ग के साथ समस्या पैदा करेगा, क्योंकि यह फू () विधि के हस्ताक्षर IFoo के विधि हस्ताक्षर से अलग है। इसके अलावा, अगर मैंने throws InterruptedExceptionफू की विधि फू () में जोड़ा है, तो मुझे एक और त्रुटि मिलेगी जिसमें कहा गया है कि फू की विधि फू () यह घोषणा करती है कि यह एक InterruptedException फेंकता है फिर भी यह एक InterruptedException को कभी नहीं फेंकता है।

जैसा कि आप देख सकते हैं (यदि मैंने इस सामान को समझाने में एक अच्छा काम किया है), तथ्य यह है कि मैं एक बाधित अपवाद को फेंक रहा हूं जैसे कि InterruptedException मुझे अपने इंटरफ़ेस IFoo को इसके कार्यान्वयन में से एक के लिए बाध्य करने के लिए मजबूर कर रहा है, जो बदले में IFoo के कहर का कारण बनता है अन्य कार्यान्वयन!

यह एक बड़ा कारण है कि जाँच किए गए अपवाद बीएडी हैं। कैप्स में।

एक समाधान चेक किए गए अपवाद को कैप्चर करना है, इसे अनियंत्रित अपवाद में लपेटें और अनियंत्रित अपवाद को फेंक दें।

Comments

हां, यह बुरा है क्योंकि आपने कहा कि आप इसे पकड़ना नहीं चाहते। लेकिन IFOO के हस्ताक्षर को प्रभावित करने से रोकने के लिए आपको करना होगा। मैं ऐसा नहीं करूंगा और एक अपवाद को पकड़ने से बचने के लिए अपने सभी इंटरफेस हस्ताक्षरों को फिर से संतुलित करने के बजाय आगे बढ़ूंगा (सिर्फ इसलिए कि अपवाद बीएडी हैं)।

— साल्वाडोर वालेंसिया

हाँ मै सह्मत हूँ। मैं किसी बात को लेकर थोड़ा अस्पष्ट था। मैं प्रचार के लिए अपवाद चाहता हूं, इसलिए मैं इससे कहीं और निपट सकता हूं। एक समाधान InterruptedException को पकड़ रहा है और एक अनियंत्रित अपवाद को फेंक रहा है। यानी हम जाँच किए गए अपवादों से बचते हैं और अनियंत्रित अपवादों के आस-पास से गुजरते हैं (भले ही वे केवल एक आवरण के रूप में समझ में आते हों)

— Blueriver

"हालांकि, यह मेरे फू वर्ग के साथ समस्याओं का कारण होगा, क्योंकि यह फू () विधि के हस्ताक्षर IFoo के विधि हस्ताक्षर से भिन्न है"। मैंने सिर्फ आपके विचार का परीक्षण किया है, और अगर हम throws InterruptedExceptionकिसी भी कार्यान्वयन में कुछ भी फेंकने के बिना IFoo के विधि हस्ताक्षर को जोड़ते हैं, तो भी संकलन करना संभव है । तो यह वास्तव में किसी भी समस्या का कारण नहीं बनता है। यदि किसी इंटरफ़ेस में आप प्रत्येक विधि हस्ताक्षर फेंक देते हैं Exception, तो यह केवल एक कार्यान्वयन को अपवाद को फेंकने या न फेंकने का विकल्प देता है (कोई भी अपवाद, जैसा कि Exceptionसभी अपवादों को अलग करता है)।

— फ़्लायआउट91

हालाँकि मैं मानता हूँ कि यह भ्रामक हो सकता है क्योंकि जब आप इस तरह के एक प्रस्तावना को लागू करेंगे और "असूचीबद्ध तरीके जोड़ें" जैसी किसी चीज़ पर क्लिक करेंगे, तो वे स्वतः ही throw Exceptionउनके हस्ताक्षर में खंड के साथ निर्मित हो जाएंगे , भले ही आपका कार्यान्वयन कुछ भी फेंके या नहीं हो सकता है एक अधिक विशिष्ट अपवाद। लेकिन मुझे अभी भी ऐसा लगता है कि इंटरफ़ेस की विधि के लिए अपवाद को हमेशा फेंकना एक अच्छा अभ्यास है क्योंकि, फिर से, यह उपयोगकर्ता को कुछ भी फेंकने या न फेंकने का विकल्प देता है।

— फ़्लायआउट91

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

— इरकॉनसन

Answer 14

• जावा अपवादों की दो श्रेणियों (जाँच और अनियंत्रित) के बीच अंतर करता है।
• जावा जाँच किए गए अपवादों के लिए एक पकड़ या घोषित आवश्यकता को लागू करता है।
• अपवाद का प्रकार निर्धारित करता है कि अपवाद की जाँच की गई है या अनियंत्रित है।
• सभी अपवाद प्रकार जो subclassesकक्षा के प्रत्यक्ष या अप्रत्यक्ष RuntimeException हैं अनियंत्रित अपवाद हैं।
• सभी वर्ग जो वर्ग से विरासत में प्राप्त होते हैं Exceptionलेकिन नहीं माने RuntimeExceptionजाते हैं checked exceptions।
• वर्ग त्रुटि से विरासत में मिली कक्षाएं अनियंत्रित मानी जाती हैं।
• कंपाइलर विधि को फेंकता है या नहीं यह निर्धारित करने के लिए प्रत्येक विधि कॉल और मंदी की जांच करता है checked exception।
  • यदि कंपाइलर सुनिश्चित करता है कि अपवाद पकड़ा गया है या फेंकता खंड में घोषित किया गया है।
• कैच-या-डिक्लेयर आवश्यकता के घोषित भाग को संतुष्ट करने के लिए, अपवाद उत्पन्न करने वाली विधि को एक throwsक्लॉज युक्त होना चाहिए checked-exception।
• Exception वर्गों को जाँचने के लिए परिभाषित किया जाता है जब उन्हें पकड़ने या घोषित करने के लिए महत्वपूर्ण माना जाता है।

Answer 15

यहां एक सरल नियम है जो आपको तय करने में मदद कर सकता है। यह संबंधित है कि जावा में इंटरफेस का उपयोग कैसे किया जाता है।

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

इंटरफ़ेस के तरीकों को देखें और उन अपवादों पर विचार करें जो वे फेंक सकते हैं:

यदि एक अपवाद विधि द्वारा कार्यान्वित किया जा सकता है, भले ही अंतर्निहित कार्यान्वयन की परवाह किए बिना (दूसरे शब्दों में, यह केवल कार्यक्षमता का वर्णन करता है) तो यह संभवतः इंटरफ़ेस में एक जाँच अपवाद होना चाहिए।

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

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

आपको आमतौर पर "बबल-अप" अपवादों (कैच और रीथ्रो) की योजना नहीं बनानी चाहिए। या तो एक अपवाद को कॉलर द्वारा नियंत्रित किया जाना चाहिए (जिस स्थिति में इसे चेक किया गया है) या इसे उच्च स्तर के हैंडलर तक सभी तरह से जाना चाहिए (जिस मामले में यह अनियंत्रित है तो सबसे आसान है)।

Answer 16

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

Answer 17

संक्षेप में, अपवाद जिन्हें आपके मॉड्यूल या ऊपर के मॉड्यूल को रनटाइम के दौरान संभालना चाहिए, उन्हें चेक अपवाद कहा जाता है; अन्य अनियंत्रित अपवाद हैं जो RuntimeExceptionया तो हैं Error।

इस वीडियो में, यह जावा में जाँच और अनियोजित अपवादों की व्याख्या करता है:
https://www.youtube.com/watch?v=ue2pOqLaArw

Answer 18

उन सभी की जाँच अपवाद हैं। अनियंत्रित अपवाद RuntimeException के उपवर्ग हैं। निर्णय यह नहीं है कि उन्हें कैसे संभालना है, यह आपका कोड उन्हें फेंक देना चाहिए। यदि आप नहीं चाहते हैं कि कंपाइलर आपको बताए कि आपने एक अपवाद नहीं संभाला है, तो आप अनियंत्रित (RuntimeException के उपवर्ग) अपवाद का उपयोग करें। उन स्थितियों के लिए सहेजा जाना चाहिए जिन्हें आप पुनर्प्राप्त नहीं कर सकते हैं, जैसे मेमोरी त्रुटियों और इस तरह से।

Comments

उम। यदि नंबरफ़ॉर्मैट अपवाद एक जाँच अपवाद है, तो जैसा आप कहते हैं, क्या यह इस तथ्य के विपरीत नहीं है कि यह RuntimeException से विरासत में मिला है ?

— EIS

क्षमा करें, मैं बहुत स्पष्ट नहीं था। मैं FileNotFoundException को नहीं बल्कि NumberFormatException की बात कर रहा था। उनके # 2 & # 4 के आधार पर, ऐसा लग रहा था कि उन्होंने सोचा था कि चेक बनाम बनाम अनचेक किया गया था कि आपने इसे पकड़ने के बाद अपवाद को कैसे संभाला था। यह कैसे परिभाषित किया गया था।

— mamboking

Answer 19

यदि कोई भी जाँच किए गए अपवादों को नापसंद करने के लिए एक और प्रमाण की परवाह करता है, तो लोकप्रिय JSON लाइब्रेरी के पहले कुछ पैराग्राफ देखें:

"हालांकि यह एक जाँच अपवाद है, यह शायद ही कभी पुनर्प्राप्त करने योग्य है। अधिकांश कॉलर्स को इस अपवाद को अनियंत्रित अपवाद और पुनर्विचार में लपेटना चाहिए:"

तो क्यों दुनिया में कोई भी डेवलपर्स को अपवाद की जाँच करता रहेगा, अगर हमें इसके बजाय "बस इसे लपेटना चाहिए"? जबरदस्त हंसी

http://developer.android.com/reference/org/json/JSONException.html

Comments

क्योंकि यह केवल सबसे अधिक कॉल करने वाले व्यक्ति हैं, सभी कॉल करने वाले नहीं हैं, जिन्हें लपेटना चाहिए और पुनर्विचार करना चाहिए। तथ्य यह है कि अपवाद की जाँच की जाती है इसका मतलब है कि फोन करने वाले को यह सोचना होगा कि क्या वे "सबसे" कॉल करने वालों में से एक हैं, या अल्पसंख्यक में से एक है जो अपवाद को संभाल सकता है और करना चाहिए।

— वारेन ड्यू

यदि आप अपने द्वारा की जाने वाली प्रत्येक कॉल के लिए त्रुटियों की जाँच करना पसंद करते हैं, तो "वापस जाएँ" सी। अपवाद आपके कोड को प्रदूषित किए बिना, सामान्य प्रोग्राम निष्पादन को असामान्य से अलग करने का एक तरीका है। अपवाद यह सुनिश्चित करते हैं कि आप किसी स्तर पर चुपचाप त्रुटि को अनदेखा नहीं कर सकते ।

— स्लावोमिर

Answer 20

जाँच किए गए अपवाद :

• रनटाइम पर प्रोग्राम के सुचारू निष्पादन के लिए कंपाइलर द्वारा जिन अपवादों की जाँच की जाती है, उन्हें चेकेड एक्सेप्शन कहा जाता है।

• ये संकलन के समय होते हैं।

• यदि इन्हें ठीक से नहीं संभाला जाता है, तो वे संकलन समय त्रुटि (अपवाद नहीं) देंगे।

• RuntimeException को छोड़कर अपवाद वर्ग के सभी उपवर्गों में जाँच अपवाद हैं।

  हाइपोथेटिकल उदाहरण - मान लीजिए कि आप परीक्षा के लिए अपना घर छोड़ रहे हैं, लेकिन यदि आप यह जांचते हैं कि आपने घर पर अपना हॉल टिकट लिया है (संकलन समय) तो परीक्षा हॉल (रनटाइम) में कोई समस्या नहीं होगी।

अनियंत्रित अपवाद :

• कंपाइलर द्वारा जिन अपवादों की जाँच नहीं की जाती है उन्हें अनियंत्रित अपवाद कहा जाता है।

• ये रनटाइम पर होते हैं।

• यदि इन अपवादों को ठीक से संभाला नहीं गया है, तो वे संकलन समय त्रुटि नहीं देते हैं। लेकिन कार्यक्रम को समय से पहले समाप्त कर दिया जाएगा।

• RunTimeException और Error के सभी उपवर्ग अनियंत्रित अपवाद हैं।

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

Answer 21

सभी अपवादों को अपवादों की जाँच करनी चाहिए।

1. अनियंत्रित अपवाद अप्रतिबंधित गोटो हैं। और अप्रतिबंधित गोटो को एक बुरी चीज माना जाता है।

2. अनियंत्रित अपवाद एनकैप्सुलेशन को तोड़ते हैं। उन्हें सही ढंग से संसाधित करने के लिए, थ्रोअर और कैचर के बीच कॉल ट्री में सभी कार्यों को बग से बचने के लिए जाना जाना चाहिए।

3. अपवाद उस फ़ंक्शन में त्रुटि हैं जो उन्हें फेंकता है लेकिन फ़ंक्शन में त्रुटियां नहीं जो उन्हें संसाधित करता है। अपवादों का उद्देश्य कार्यक्रम को एक और संदर्भ के लिए एक त्रुटि है या नहीं, इस निर्णय को स्थगित करके एक दूसरा मौका देना है। यह केवल दूसरे संदर्भ में ही सही निर्णय हो सकता है।