RuntimeException

Question

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

किसी भी तरह का रनटाइम अपवाद स्वीकार्य है? यदि हां, तो अन्य परिदृश्य क्या हैं जहां रनटाइम अपवादों को पकड़ना ठीक है?

Answer 1

आप किसी भी अपवाद को पकड़ने के लिए RuntimeException पकड़ते हैं: आप इसके साथ कुछ करने की योजना बना रहे हैं। शायद आप अपवाद के कारण जो कुछ भी सही कर सकते हैं। शायद आप बस एक अलग अपवाद प्रकार के साथ फिर से फेंकना चाहते हैं।

कैचिंग और को अनदेखा कर रहा है, हालांकि, यह बेहद खराब अभ्यास है।

Answer 2

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

आखिरी जावा प्रोजेक्ट जिस पर मैंने काम किया था, उसी तरह से एक समान दृष्टिकोण था, हम अपवाद लॉग करेंगे ताकि अगर कोई उपयोगकर्ता किसी बग के बारे में शिकायत कर रहा हो, तो हम यह पता लगा सकते हैं कि वास्तव में क्या हुआ और देखें कि त्रुटि कहां है हुई।

संपादित करें 1: kdgregory के रूप में कहा, दो अलग बातें पकड़ने और अनदेखी कर रहे हैं, आम तौर पर, लोगों को बाद :-)

Answer 3

RuntimeException प्रोग्रामर त्रुटियों के लिए इस्तेमाल किया जा करने का इरादा है करने का विरोध कर रहे हैं। इस तरह इसे कभी पकड़ा नहीं जाना चाहिए। कुछ मामलों में जहां यह होना चाहिए:

1. आप कोड है कि एक 3 पार्टी आप जब वे अपवाद फेंक पर नियंत्रण की जरूरत नहीं है, जहां से आता है बुला रहे हैं। मैं तर्क दूंगा कि आपको मामले के आधार पर ऐसा करना चाहिए और अपने स्वयं के वर्गों में तीसरे पक्ष के कोड के उपयोग को लपेटना चाहिए ताकि आप गैर-रनटाइम अपवादों को वापस कर सकें।

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

अपने विशिष्ट मामले में मैं सवाल करने के लिए कारण है कि आप RuntimeExceptions कर रहे हैं होता परीक्षण में होते हैं - आप उन्हें बजाय फिक्सिंग जाना चाहिए उनके आसपास काम कर रहे।

तो आपको यह गारंटी देनी चाहिए कि जब आप प्रोग्राम से बाहर निकलना चाहते हैं तो आपका कोड केवल रनटाइम अपवादों को फेंकता है। जब आप इसे लॉग करना और बाहर निकलना चाहते हैं तो आपको केवल RuntimeExceptions को पकड़ना चाहिए। RuntimeExceptions के इरादे से यही है।

You can look at this discussion कुछ अन्य कारणों से लोगों को ... मुझे व्यक्तिगत रूप से जवाबों में एक अनिवार्य कारण नहीं मिला है।

Answer 4

मेरे कोड में 99% अपवाद रनटाइम_एसेप्शन से व्युत्पन्न हैं।

कारणों मैं अपवाद को पकड़ने के हैं:

• पकड़ने के लिए लॉग और फिक्स समस्या।
• लॉग को पकड़ें और अधिक विशिष्ट अपवाद उत्पन्न करें और
• पकड़ें लॉग और को पुनर्स्थापित करें।
• पकड़ने के लिए लॉग और मारने के ऑपरेशन (छोड़ें अपवाद)
  • उपयोगकर्ता/अनुरोध आपने कार्रवाई विफल रहता है।
    उदाहरण के लिए एक HTTP अनुरोध हैंडलर। मैं सेवा को नीचे लाने के बजाए अनुरोधित ऑपरेशन मर जाऊंगा। (हालांकि अधिमानतः हैंडलर को 500 त्रुटि कोड वापस करने के लिए पर्याप्त समझ है।)
  • टेस्ट केस एक अपवाद के साथ पास/विफल हुआ।
  • सभी अपवाद मुख्य धागे में नहीं हैं।
    धागे से बचने के लिए अपवादों को आवंटित करना आमतौर पर बुरी तरह से प्रलेखित होता है लेकिन आम तौर पर कार्यक्रम की समाप्ति (बिना अवांछित ढेर के) का कारण बनता है।

Answer 5

जब तक आप एक RuntimeException सही कर सकते हैं, तो आप इसे पकड़ने के लिए नहीं चाहता ...

... केवल देखने के एक बिंदु से डेवलपर्स सच ....

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

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

Answer 6

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

Answer 7

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

एक और आम स्थिति एक सर्वर है; आप सिर्फ इसलिए बंद नहीं करना चाहते हैं क्योंकि एक अनुरोध उस तरीके से विकृत हो गया था जिसकी आपने अपेक्षा नहीं की थी। (जब तक यह वास्तव में असंगत स्थिति की संभावनाओं को कम करने के लिए वास्तव में महत्वपूर्ण नहीं है।)

इनमें से किसी भी परिस्थिति में, उचित काम करना लॉग/रिपोर्ट अपवाद है और शेष कार्यों के साथ जारी है।

एक अस्पष्ट किसी भी अपवाद के सामान्यीकरण सकता है: यह एक अपवाद "को पकड़ने के लिए उपयुक्त" है अगर और सिर्फ़ अगर वहाँ कुछ समझदार क्या करना यह पकड़ने के बाद है: कैसे अपने कार्यक्रम जारी रखना चाहिए।

Answer 8

साल पहले, हमने एक नियंत्रण प्रणाली ढांचा लिखा था और एजेंट ऑब्जेक्ट्स रनटाइम अपवाद पकड़े थे, अगर वे कर सकते थे और जारी रखे तो उन्हें लॉग इन किया।

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

तो फ्रेमवर्क/"बाहर निकलना नहीं चाहिए" कोड में मुझे लगता है कि यह उचित हो सकता है। और जब यह काम करता है तो यह बहुत अच्छा है।

कोड बहुत ठोस था, लेकिन यह हार्डवेयर चला गया, और हार्डवेयर कभी-कभी खराब जवाब देता है।

इसे एक समय में महीनों के लिए मानव हस्तक्षेप के बिना चलाने के लिए डिज़ाइन किया गया था। यह हमारे परीक्षणों में बेहद अच्छी तरह से काम किया।

त्रुटि पुनर्प्राप्ति कोड के हिस्से के रूप में, यह यूपीएस की एन मिनट में बंद होने और एम मिनट में चालू करने की क्षमता का उपयोग करके पूरी इमारत को रीबूट करने का सहारा ले सकता है।

कभी कभी हार्डवेयर दोष साइकिल सत्ता में :)

तो मुझे याद है, एक असफल शक्ति चक्र के बाद अंतिम उपाय हुए कहा कि यह एक ईमेल भेज यह मालिकों है के लिए गया था, की जरूरत है "मैं और अपने आप को ठीक करने की कोशिश की मैं कर सकते हैं ' टी; समस्या उपप्रणाली XYZ में है ", और हमें एक समर्थन कॉल बढ़ाने के लिए एक लिंक शामिल किया गया।

दुर्भाग्य से इस परियोजना से पहले ही बन सकता है डिब्बा बंद हो गया स्वयं जागरूक:)>

Answer 9

हम सभी जानते हैं कि अपवाद की जाँच की और RuntimeExceptions अपवाद की दो श्रेणियां हैं। यह हमेशा सुझाव दिया जाता है कि हम चेक अपवादों को (या तो कोशिश करें या पकड़ें) को संभालें क्योंकि वे प्रोग्रामिंग स्थितियां हैं जहां दुर्भाग्यवश प्रोग्रामर स्वयं कुछ भी नहीं कर सकता है; तरह FileNotFoundException यह प्रोग्रामर जो उपयोगकर्ता की ड्राइव पर फ़ाइलों डालता है, तो कार्यक्रम वास्तव में फ़ाइल 1.txt जो बयान के साथ उपयोगकर्ता की f:\ पर वहाँ माना जाता है पढ़ने के लिए कोशिश कर रहा है नहीं है: यदि फ़ाइल पाया जाता है

File f11 = new File("f:\\1.txt"); 
FileInputStream fos = new FileInputStream(f11); 

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

मुझे दूसरे परिदृश्य को भी समझाएं जिसके साथ RuntimeException की अवधारणा स्पष्ट हो जाएगी। कोड निम्नलिखित पर विचार करें:

int a = {1,2,3,4,5}; 
System.out.println(a[9]); 

इस गरीब कोडिंग जो ArrayIndexOutOfBoundsException उत्पन्न करता है। जो RuntimeException का उदाहरण है। इसलिए प्रोग्रामर को वास्तव में अपवाद को संभालना नहीं चाहिए, इसे प्रोग्राम को क्रैश करने दें, और बाद में तर्क को ठीक करें।

Answer 10

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

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

यहां नीचे पंक्ति दिशानिर्देश है।

जावा Docs से। कृपया यह Unchecked Exceptions — The Controversy