क्या किसी पकड़े गए अपवाद को कभी भी अनदेखा करने का कोई वैध कारण

Question

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

Exceptions.DontSwallowErrorsCatchingNonspecificExceptionsRule : 2106 defects 

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

Answer 1

हालांकि अपवादों को अनदेखा करने के कुछ उचित कारण हैं; हालांकि, आम तौर पर यह केवल विशिष्ट अपवाद है कि आप सुरक्षित रूप से अनदेखा कर सकते हैं। जैसा कि Konrad Rudolph द्वारा नोट किया गया है, आपको ढांचे के हिस्से के रूप में एक त्रुटि को पकड़ना और निगलना पड़ सकता है; और जैसा कि osp70 द्वारा नोट किया गया है, वहां एक ढांचे द्वारा उत्पन्न अपवाद हो सकता है जिसे आप जानते हैं कि आप अनदेखा कर सकते हैं।

इन दोनों मामलों में, हालांकि, आप अपवाद प्रकार पता होने की संभावना होगी और यदि आप प्रकार पता तो आप निम्न के समान कोड होना चाहिए:

try { 
    // Do something that might generate an exception 
} catch (System.InvalidCastException ex) { 
    // This exception is safe to ignore due to... 
} catch (System.Exception ex) { 
    // Exception handling 
} 

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

Answer 2

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

हालांकि, मैं त्रुटि लॉग करता हूं। मैं बस इसे पुनर्स्थापित नहीं करता हूं।

Answer 3

यह ढांचे पर निर्भर करता है। खराब रूप से लागू ढांचे को वास्तव में इसकी आवश्यकता हो सकती है। मुझे वीबी 6 में एक हैक याद है जहां यह निर्धारित करने का कोई तरीका नहीं था कि संग्रह में कोई तत्व है या नहीं। तत्व को पुनर्प्राप्त करने और त्रुटि को निगलने का प्रयास करने का एकमात्र तरीका था।

Answer 4

मैं अपवाद नहीं पकड़ता जब तक कि मैं उनके बारे में कुछ करने की योजना नहीं बनाता। उन्हें अनदेखा करना उनके बारे में कुछ नहीं कर रहा है।

Answer 5

महत्वपूर्ण कोड में, शायद नहीं, क्योंकि कार्यक्रम की स्थिति हमेशा बिल्कुल परिभाषित की जानी चाहिए। आपके डेटाबेस कॉल उदाहरण की तरह।

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

Answer 6

हां, मैक्सिम की प्रति पोस्ट कुछ परिस्थितियों में स्वीकार्य (अपरिहार्य, आवश्यक)। इसका मतलब यह नहीं है कि आपको इसे पसंद करना है। 2106 उल्लंघन शायद बहुत अधिक हैं और कम से कम उन्हें पकड़ ब्लॉक में एक टिप्पणी जोड़नी चाहिए क्योंकि इस अपवाद को निगलना ठीक क्यों था।

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

Answer 7

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

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

यह कहने के लिए संपादित किया गया कि इनमें से किसी भी मामले में, आप कम से कम ईवेंट को लॉग करना चाहते हैं।

Answer 8

यह करना वास्तव में एक बुरी चीज है।

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

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

Answer 9

मुझे लगता है कि अगर आप एक खाली कैच ब्लॉक है आप दस्तावेज़ के लिए कारण है कि यह रिक्त है ताकि अगली डेवलपर पता चल जाएगा की जरूरत है। उदाहरण के लिए server.transfer पर एक वेब अपवाद कभी-कभी फेंक दिया जाता है। मैं इसे पकड़ता हूं और टिप्पणी करता हूं कि हम स्थानांतरण कॉल के कारण इसे अनदेखा कर सकते हैं।

Answer 10

आम तौर पर कोई है, वास्तव में नहीं सभी मामलों का 99% है, लेकिन

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

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

Answer 11

मेरी भावना यह है कि किसी भी खाली कैच ब्लॉक को एक टिप्पणी की आवश्यकता है।

संभवतः कुछ त्रुटियों को अनदेखा करने के लिए मान्य है, लेकिन आपको अपने कारणों को दस्तावेज करने की आवश्यकता है।

इसके अलावा, आप यह एक सामान्य "पकड़ (अपवाद ई) {}" बनाने के लिए नहीं करना चाहते।

आपको केवल उस विशिष्ट त्रुटि प्रकार को पकड़ना चाहिए जिसकी अपेक्षा की जाती है और इसे सुरक्षित रूप से अनदेखा किया जाता है।

Answer 12

जब अपवादों की बात आती है, हमेशा अपवाद होते हैं।

Answer 13

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

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

Answer 14

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

public void testSomething(){ 
    try{ 
     fooThatThrowsAnException(parameterThatCausesTheException); 
     fail("The method didn't throw the exception that we expected it to"); 
    } catch(SomeException e){ 
     // do nothing, as we would expect this to happen, if the code works OK. 
    } 
} 

ध्यान दें कि, हालांकि कैच ब्लॉक कुछ भी नहीं करता है, यह बताता है कि क्यों।

करने के बाद कहा कि यह, और हाल ही में परीक्षण चौखटे (Junit4 & TestNG) आप अपवाद है कि उम्मीद है निर्दिष्ट कर सकते हैं - जो इस तरह somthing की ओर जाता है ...

@Test(expected = SomeException.class) 
public void testSomething(){ 
    fooThatThrowsAnException(parameterThatCausesTheException); 
    fail("The method didn't throw the exception that we expected it to"); 
} 

Answer 15

निम्नलिखित केवल भाषाओं पर लागू होने वाला अपवादों की जांच की है, उदाहरण के लिए जावा:

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

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

Answer 16

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

Answer 17

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

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

Answer 18

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

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

यदि यह घर में काम करता है, तो उस टीम/व्यक्ति के परिणाम होंगे जो घटिया काम का उत्पादन करते हैं। हो सकता है कि इसका मतलब यह होगा कि उन्हें इसे ठीक करने के लिए रातें और सप्ताहांत काम करना है, लेकिन वे इसके लिए एक तरफ या दूसरे पर हुक पर होंगे। ठेकेदारों को भी ऐसा ही लागू होना चाहिए, संभवतः और भी बहुत कुछ।

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

Answer 19

मुझे इस विशिष्ट के बारे में बहुत आश्चर्य है।

Connection con = DriverManager.getConnection(url, "***", "***"); 

try { 
    PreparedStatement pStmt = con.prepareStatement("your query here"); 

    ... // query the database and get the results 
} 
catch(ClassNotFoundException cnfe) { 
    // real exception handling goes here 
} 
catch(SQLException sqle) { 
    // real exception handling goes here 
} 
finally { 
    try { 
     con.close(); 
    } 
    catch { 
     // What do you do here? 
    } 
} 

मुझे कभी नहीं पता कि अंत में ब्लॉक में उस अंतिम पकड़ में क्या करना है। मैंने कभी नहीं देखा है() पहले एक अपवाद फेंक दिया है, और यह इतना असंभव है कि मुझे इसके बारे में चिंता न करें। मैं बस अपवाद लॉग और आगे बढ़ना।

Answer 20

निश्चित रूप से ऐसी परिस्थितियां हैं जहां एक विशिष्ट अपवाद पकड़ना और कुछ भी नहीं करना ठीक है। ,,

public FileStream OpenFile(string path) 
    { 
     FileStream f = null; 
     FileInfo fi = new FileInfo(path); 
     if (fi.Exists) 
     { 
      f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);     
     } 
     return f; 
    } 

इस मामले में अपवाद को पकड़ने (बहुत) है मामूली सुरक्षित के रूप में फ़ाइल के बीच से हटा दिया जाता सकता है:

public FileStream OpenFile(string path) 
    { 
     FileStream f = null; 
     try 
     { 
      f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite); 
     } 
     catch (FileNotFoundException) 
     { 
     } 
     return f; 
    } 

तुम भी विधि इस तरह से लिख सकते हैं: यहाँ एक तुच्छ उदाहरण है जब आप इसके अस्तित्व की जांच करते हैं और जिस समय आप इसे खोलते हैं।

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

लेकिन यह विशिष्ट अपवाद को अनदेखा कर रहा है। यह कोड:

catch 
{ 
} 

अक्षम्य है।

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

यदि आपको नहीं पता कि किस प्रकार का अपवाद फेंक दिया जा सकता है, तो आप नहीं जानते कि आपका कोड कैसा असफल हो सकता है। यदि आपको नहीं पता कि आपका कोड कैसा असफल हो सकता है, तो आपके पास यह मानने का कोई आधार नहीं है कि यह प्रसंस्करण जारी रखना ठीक है या नहीं।

Answer 21

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

Answer 22

जब तक अपनी पकड़ कोड या तो

1. लॉग अपवाद
2. repackage होगा एक और अपवाद है कि एक ही अमूर्त से मेल खाता में अपवाद। और फेंक फिर
3. अपवाद जिस तरह से आप उपयुक्त देख

आप अपवाद अनदेखा कर सकते हैं संभालती है, लेकिन कम से कम विधि डॉक्स में उम्मीद अपवाद उल्लेख है, तो उपभोक्ता की उम्मीद है और यदि आवश्यक हो तो संभाल

कर सकते हैं

Answer 23

जावा दुनिया में जहां यह ठीक है से एक उदाहरण लेते हैं एक अपवाद की अनदेखी करने के:

String foo="foobar"; 
byte[] foobytes; 

try 
{ 
    foobytes=foo.getBytes("UTF-8"); 
} 
catch (UnsupportedEncodingException uee) 
{ 
    // This is guaranteed by the Java Language Specification not to occur, 
    // since every Java implementation is required to support UTF-8. 
} 

जिसके अनुसार, यहां तक ​​कि इस तरह की परिस्थितियों में, मैं अक्सर उपयोग करेंगे

... 
catch (UnsupportedEncodingException uee) 
{ 
    // This is guaranteed by the Java Language Specification not to occur, 
    // since every Java implementation is required to support UTF-8. 
    uee.printStackTrace(); 
} 

आभासी मशीन पागल/कल्पना तोड़ने होने जा रहा है, तो बहुत कम मैं इसके बारे में क्या कर सकते हैं, लेकिन स्टैक ट्रेस के साथ, मैं कम से कम जब यह पागलपन में अपने वंश शुरू कर दिया नोटिस मिलता है ..

Answer 24

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