java - चेक और अनचेक अपवादों का चयन कब करें




exception checked-exceptions (12)

जावा (या चेक अपवादों वाली किसी अन्य भाषा में), अपनी अपवाद कक्षा बनाते समय, आप कैसे तय करते हैं कि इसे चेक किया जाना चाहिए या अनचेक किया जाना चाहिए?

मेरा वृत्ति यह कहना है कि उन मामलों में एक अपवाद अपवाद कहा जाएगा जहां कॉलर कुछ उत्पादक तरीके से ठीक हो सकता है, जहां एक अनचेक अपवाद अप्राप्य मामलों के लिए अधिक होगा, लेकिन मुझे दूसरे के विचारों में दिलचस्पी होगी।


मैं जिस नियम का उपयोग करता हूं वह है: अनचेक अपवादों का कभी भी उपयोग न करें! (या जब आप इसके चारों ओर कोई रास्ता नहीं देखते हैं)

इसके विपरीत एक बहुत मजबूत मामला है: कभी भी अपवादों का उपयोग न करें। मैं बहस में पक्ष लेने के लिए अनिच्छुक हूं लेकिन व्यापक सहमति है कि चेक अपवादों को पेश करना हिंडसाइट में गलत निर्णय था। कृपया संदेशवाहक को शूट न करें और those arguments संदर्भ लें।


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


चेक किए गए अपवाद पुनर्प्राप्ति योग्य मामलों के लिए उपयोगी होते हैं जहां आप कॉलर को जानकारी प्रदान करना चाहते हैं (यानी अपर्याप्त अनुमतियां, फ़ाइल नहीं मिली, आदि)।

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


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

जांच किए गए अपवादों का अनुमान लगाने योग्य , लेकिन अपरिवर्तनीय त्रुटियों के लिए उपयोग किया जाना चाहिए जो पुनर्प्राप्त करने के लिए उचित हैं।

अनचेक अपवादों का उपयोग बाकी सब कुछ के लिए किया जाना चाहिए।

मैं इसे आपके लिए तोड़ दूंगा, क्योंकि ज्यादातर लोग गलत समझते हैं इसका क्या अर्थ है।

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

जब तक आप जो अपवाद फेंक रहे हैं, तब तक उपरोक्त सभी स्थितियों को पूरा नहीं किया जाता है, इसे अनचेक अपवाद का उपयोग करना चाहिए।

प्रत्येक स्तर पर पुनर्मूल्यांकन करें : कभी-कभी चेक अपवाद को पकड़ने वाली विधि त्रुटि को संभालने के लिए सही जगह नहीं है। उस स्थिति में, अपने कॉलर्स के लिए उचित क्या है पर विचार करें। यदि अपवाद अनुमानित है, तो उनके लिए पुनर्प्राप्त करने के लिए अपरिवर्तनीय और उचित है तो आपको स्वयं को एक चेक अपवाद फेंकना चाहिए। यदि नहीं, तो आपको अपरिचित अपवाद में अपवाद लपेटना चाहिए। यदि आप इस नियम का पालन करते हैं तो आप अनचाहे अपवादों के लिए चेक अपवादों को परिवर्तित कर पाएंगे और इसके विपरीत आप किस स्तर पर हैं।

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


तुम सही हो।

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

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

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

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

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

और आपको पता चलेगा कि क्या हुआ। "प्रतिनिधिेटवर्कवर्क" विधि (लाइन 4569 पर) में अन्य क्लास ने आपकी कक्षा को "निकास" मान के साथ बुलाया, भले ही इसे आदि न हो।

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

NullPointerExceptions के साथ वही बात होती है। यदि आपके पास कुछ 15 विधियों के साथ 700 लाइन वर्ग है, जो 30 विशेषताओं का उपयोग करता है और उनमें से कोई भी शून्य नहीं हो सकता है, तो उन सभी विधियों में निरर्थकता के सत्यापन के बजाय आप उन सभी विशेषताओं को केवल पढ़ने के लिए बना सकते हैं और उन्हें कन्स्ट्रक्टर में मान्य कर सकते हैं या फैक्टरी विधि।

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

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

उस परिदृश्य में ऐसा कुछ भी नहीं है जिसे आप या आपके सहकर्मी इसकी मदद करने के लिए कर सकते हैं। लेकिन फिर भी आपको कुछ करना है और उपयोगकर्ता को सिर्फ आंखों में मरने और गायब होने की अनुमति नहीं देना है। आप इसके लिए एक चेक अपवाद का उपयोग करते हैं और अपवाद को संभालते हैं, जब ऐसा होता है तो आप क्या कर सकते हैं? अधिकांश समय, त्रुटि को लॉग करने का प्रयास करने के लिए, शायद अपना काम (ऐप काम) सहेजें और उपयोगकर्ता को एक संदेश प्रस्तुत करें । (साइट blabla नीचे है, कृपया बाद में पुनः प्रयास करें आदि)

यदि चेक अपवाद अधिक उपयोग किया जाता है (सभी विधियों के हस्ताक्षर में "फेंक अपवाद" जोड़कर), तो आपका कोड बहुत नाजुक हो जाएगा, क्योंकि हर कोई उस अपवाद को अनदेखा कर देगा (क्योंकि बहुत सामान्य है) और कोड की गुणवत्ता गंभीरता से होगी समझौता किया।

यदि आप अनचेक अपवाद का उपयोग करते हैं तो ऐसा कुछ भी होगा। उस कोड के उपयोगकर्ताओं को पता नहीं है कि कुछ गलत हो सकता है अगर बहुत कोशिश करें {...} पकड़ें (थ्रोबल टी) दिखाई देगा।


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


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

मुझे कार्यान्वयन विस्तार के रूप में निचले स्तर पर उपयोगी अपवाद उपयोगी लगता है। यह निर्दिष्ट त्रुटि "रिटर्न कोड" प्रबंधित करने के बजाय अक्सर नियंत्रण तंत्र के बेहतर प्रवाह की तरह लगता है। यह कभी-कभी निम्न स्तर के कोड परिवर्तन के लिए किसी विचार के प्रभाव को देखने में सहायता कर सकता है ... एक चेक अपवाद डाउनस्ट्रीम घोषित करें और देखें कि समायोजित करने की आवश्यकता किसके लिए होगी। यह आखिरी बिंदु लागू नहीं होता है यदि बहुत सारे सामान्य हैं: पकड़ (अपवाद ई) या अपवाद फेंकता है जो आमतौर पर बहुत अच्छी तरह से सोचा नहीं जाता है।


मैं जिस नियम का उपयोग करता हूं वह है: अनचेक अपवादों का कभी भी उपयोग न करें! (या जब आप इसके चारों ओर कोई रास्ता नहीं देखते हैं)

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

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


यहां आपके चेक किए गए / अनचेक दुविधा के लिए एक बहुत ही सरल समाधान है।

नियम 1: कोड निष्पादित करने से पहले एक अनदेखी अपवाद के रूप में एक परीक्षण योग्य स्थिति के रूप में सोचें। उदाहरण के लिए…

x.doSomething(); // the code throws a NullPointerException

जहां एक्स शून्य है ... ... कोड संभवतः निम्नलिखित होना चाहिए ...

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

नियम 2: जांच किए गए अपवाद को एक गैर-परीक्षण योग्य स्थिति के रूप में सोचें जो कोड निष्पादित होने पर हो सकता है।

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

... उपर्युक्त उदाहरण में, DNS सर्वर डाउन होने के कारण URL (google.com) अनुपलब्ध हो सकता है। यहां तक ​​कि तत्काल भी DNS सर्वर काम कर रहा था और 'google.com' नाम को आईपी पते पर हल कर रहा था, अगर कनेक्शन google.com पर किया जाता है, तो किसी भी समय बाद में, नेटवर्क नीचे जा सकता है। धाराओं को पढ़ने और लिखने से पहले आप बस नेटवर्क का परीक्षण नहीं कर सकते हैं।

ऐसे समय होते हैं जब कोड को हल करने से पहले कोड को निष्पादित करना चाहिए। डेवलपर्स को अपने कोड को चेक इन अपवाद के माध्यम से इन स्थितियों को संभालने के लिए मजबूर करने के लिए मजबूर करने के लिए मजबूर कर रहा है, मुझे जावा के निर्माता को अपनी टोपी टिपनी है जिसने इस अवधारणा का आविष्कार किया।

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

इसके लिए एक भूरा क्षेत्र है। ऐसी स्थिति में जब कई परीक्षणों की आवश्यकता होती है (यदि मस्तिष्क को बहुत सारे && और || के साथ बयान दिया जाता है), तो अपवाद को हटाया जाना चाहिए क्योंकि यह सही होने के लिए बहुत अधिक दर्द है - आप बस यह समस्या नहीं कह सकते एक प्रोग्रामिंग त्रुटि है। यदि 10 से कम परीक्षण हैं (उदाहरण के लिए 'if (x == null)'), तो प्रोग्रामर त्रुटि एक अनचेक अपवाद होना चाहिए।

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

उपरोक्त 2 नियम शायद आपकी चिंता का 9 0% निकाल देंगे जिस पर से चुनना है। नियमों को सारांशित करने के लिए, इस पैटर्न का पालन करें ... 1) अगर निष्पादित करने के लिए कोड को निष्पादित करने के लिए इसे निष्पादित करने से पहले परीक्षण किया जा सकता है और यदि कोई अपवाद होता है - एक प्रोग्रामर त्रुटि उर्फ, अपवाद एक अनचेक अपवाद होना चाहिए (रनटाइम अपवाद का उप-वर्ग )। 2) यदि निष्पादित करने के लिए कोड को सही तरीके से चलाने के लिए इसे निष्पादित करने से पहले परीक्षण नहीं किया जा सकता है, तो अपवाद एक जांच अपवाद (अपवाद का उप-वर्ग) होना चाहिए।


यहां मेरा अंगूठा का अंतिम नियम है।
मैं उपयोग करता हूं:

  • कॉलर के कारण विफलता के लिए मेरी विधि के कोड के भीतर अनचेक अपवाद (जिसमें एक स्पष्ट और पूर्ण दस्तावेज शामिल है )
  • callee कारण विफलता के लिए अपवाद की जांच की गई है जिसे मुझे अपने कोड का उपयोग करने के इच्छुक व्यक्ति को स्पष्ट करने की आवश्यकता है

पिछले उत्तर की तुलना करें, यह एक या दूसरे (या दोनों) प्रकार के अपवादों के उपयोग के लिए एक स्पष्ट तर्क है (जिस पर कोई सहमत या असहमत हो सकता है)।

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

तो उदाहरण के लिए, नीचे दिए गए इस विशेष कार्य का लक्ष्य किसी वस्तु को बनाना (या यदि पहले से मौजूद हो) प्राप्त करना है,
अर्थ:

  • ऑब्जेक्ट का कंटेनर बनाने / प्राप्त करने के लिए मौजूद होना चाहिए (कॉलर की ज़िम्मेदारी
    => अनचेक अपवाद, और इस बुलाए गए फ़ंक्शन के लिए स्पष्ट जावाडोक टिप्पणी)
  • अन्य पैरामीटर शून्य नहीं हो सकते हैं
    (कॉलर पर रखने के लिए कोडर की पसंद: कोडर शून्य पैरामीटर की जांच नहीं करेगा लेकिन कोडर दस्तावेज करता है)
  • नतीजा न हो सकता है
    (कैली के कोड की जिम्मेदारी और पसंद, पसंद जो कॉलर के लिए बहुत रुचि होगी
    => अपवाद की जांच की गई है क्योंकि प्रत्येक कॉलर को निर्णय लेना चाहिए यदि ऑब्जेक्ट बनाया / पाया नहीं जा सकता है, और यह निर्णय संकलन समय पर लागू किया जाना चाहिए: वे इस फ़ंक्शन का उपयोग इस संभावना से निपटने के बिना नहीं कर सकते हैं, जिसका अर्थ यह चेक किया गया है अपवाद)।

उदाहरण:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

एक जावा Learner से :

जब कोई अपवाद होता है, तो आपको अपवाद को पकड़ना और संभालना होगा, या संकलक को बताना होगा कि आप यह घोषणा करके इसे संभाल नहीं सकते हैं कि आपकी विधि उस अपवाद को फेंकता है, फिर आपके विधि का उपयोग करने वाले कोड को उस अपवाद को संभालना होगा (यहां तक ​​कि यह भी यह भी घोषित करना चुन सकता है कि यह अपवाद फेंकता है अगर यह इसे संभाल नहीं सकता है)।

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

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


चेक अपवाद: यदि क्लाइंट अपवाद से पुनर्प्राप्त हो सकता है और जारी रखना चाहते हैं, तो चेक अपवाद का उपयोग करें।

अनचेक अपवाद: यदि कोई ग्राहक अपवाद के बाद कुछ भी नहीं कर सकता है, तो अनचेक अपवाद उठाएं।

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

here देखें





checked-exceptions