त्रुटियों को कोई संभाल नहीं सकता

एक किताब से दूसरी में, लेख से लेख तक, यह राय कि अभिव्यक्ति

try { //do something } catch(Exception ex) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



इस लेख का उद्देश्य मौजूदा अवधारणाओं को "फैलाना" नहीं है, क्योंकि लेखक को सर्वश्रेष्ठ दृष्टिकोण नहीं पता है। लेख का उद्देश्य अपवादों से निपटने की समस्या को बढ़ाना है और इस तथ्य को स्वीकार करना है कि यह केवल " catch(Exception)



नहीं करें catch(Exception)



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



शुरू करने के लिए, मैं अपने दो लेखों के अनुवाद की शुरुआत करना चाहता हूँ:

1. जाँच अपवाद के साथ समस्याएँ। एंडर्स हेल्सबर्ग के साथ बातचीत। भाग २।अगस्त १ 18, २००३

2. अपरिवर्तनीय अपवादों के साथ जीवन। ३ मार्च २०१४



मैं यह भी उल्लेख करना चाहूंगा कि संक्षिप्तता के लिए मैंने इन सभी लेखों का बिल्कुल अनुवाद नहीं किया है। ये क्लिपिंग्स हैं जो किसी विषय के संदर्भ में सबसे महत्वपूर्ण हैं। मैं पाठ को स्वयं से निम्नानुसार फ़्रेम करूँगा: Spock speech पाठ अंत Spock भाषण

जाँच अपवाद के साथ समस्याएँ।

ब्रूस एकेल : C # में जाँच अपवादों के लिए एक तंत्र नहीं है। C # में जाँच अपवादों को सक्षम करने या न करने का निर्णय कैसे किया गया था?

एंडर्स हेजलबर्ग : मुझे जांचे गए अपवादों के साथ दो समस्याएं दिखाई देती हैं: स्केलेबिलिटी और वर्जनिंग।

ब्रूस एकेल : मैं सोचता था कि चेक किए गए अपवाद शांत हैं।

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

ब्रूस एकेल : क्या जाँच अपवादों के संबंध में C # विकास टीम में कोई असहमति थी?

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

ब्रूस एकेल : चरम प्रोग्रामिंग डेवलपर्स कहते हैं "इसे काम करना सबसे आसान है।"

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

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

एंडर्स हेजलसबर्ग : आइए संस्करण के साथ शुरू करें, क्योंकि यहां की समस्याएं देखने में आसान हैं। मान लें कि मैं एक विधि foo



बनाता हूं जो अपवादों A, B और C. को फेंकने की घोषणा करता है। विधि के दूसरे संस्करण में, मैं कुछ चिप्स जोड़ना चाहता हूं और अब foo



विधि अपवाद को फेंक सकती है। एक नया अपवाद जोड़ना एक असंगत परिवर्तन है, क्योंकि इस पद्धति के मौजूदा उपयोगकर्ता लगभग 100 हैं। % इस अपवाद को नहीं पकड़ेंगे।

एक नया अपवाद जोड़ने से ग्राहक कोड टूट जाता है। यह एक इंटरफ़ेस में एक विधि जोड़ने जैसा है।

बिल वेनर : लेकिन क्या आप क्लाइंट कोड को वैसे भी तोड़ रहे हैं, भले ही भाषा में कोई अपवाद न हो?

एंडर्स हेजेल्सबर्ग : नहीं, क्योंकि बड़ी संख्या में लोग "नशे में" हैं। वे इनमें से किसी भी अपवाद को पकड़ने नहीं जा रहे हैं। निचले स्तर पर, संदेश लूप के चारों ओर एक अपवाद हैंडलर है। यह हैंडलर बस एक खिड़की दिखाता है जिसमें कहा गया है कि कुछ गलत हो गया है। प्रोग्रामर अपने कोड को हर जगह try\finally



साथ कवर करके संरक्षित करते हैं, ताकि वे केवल अपवाद को संसाधित करने से बचें, यह अपवाद था जो वे संभाल नहीं रहे थे।

बिल वेनर : सामान्य तौर पर, क्या आपको लगता है कि सबसे आम मामले में, उपयोगकर्ता स्पष्ट रूप से अपवादों को संभालने के लिए स्टैक के शीर्ष पर एक हैंडलर पसंद करते हैं?

एंडर्स हेजलबर्ग : यह मजेदार है कि लोग सोचते हैं कि अपवादों के साथ संबंधों का सबसे महत्वपूर्ण हिस्सा उन्हें संभाल रहा है। यह सिर्फ इतना महत्वपूर्ण नहीं है। एक अच्छी तरह से लिखे गए एप्लिकेशन में, निर्माणों को try\catch



लिए try\catch



try\finally



की try\finally



का अनुपात लगभग 10 से 1 है।

बिल वेनर : तो इसका परिणाम क्या है?

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

अपवाद हैंडलिंग को केंद्रीकृत किया जाना चाहिए और आपको केवल अपनी सुरक्षा करनी चाहिए, जबकि अपवाद हैंडलर को प्रचारित किए जाते हैं।



भाषण देते हैं

स्केलेबिलिटी के साथ समस्या एंडर्स हेल्सबर्ग द्वारा प्रस्तावित अपवाद हैंडलिंग के अर्थ को नहीं बदलती है, इसलिए इस विषय के दृष्टिकोण से अनुवाद करना (जो कोई भी इच्छुक व्यक्ति देख सकता है और देख सकता है, उसे बाहर निकालना उचित नहीं है, लेकिन सामान्य तौर पर यह इस तथ्य से नीचे आता है कि कार्यक्रम की वृद्धि के साथ, उत्सर्जित संख्या) अपवाद से बढ़ रहा है, और कोई भी, उन सब को संभालने के लिए विशेष रूप से तरीकों कि एक दर्जन या अपवाद के दो विभिन्न प्रकार पार कर सकते हैं सक्षम हो जाएगा, अपने संचालकों नरक footcloths में बदल जाएगा try\catch



और कोड समर्थित असंभव हो जाता है हो)।

हाल ही में, 3 मार्च 2014 को, एरिक लिपर्ट ने अपने ब्लॉग पर C # में अपवाद से निपटने का विषय भी उठाया।

उन्होंने चर्चा को दो भागों में विभाजित किया: पहले भाग में उन्होंने कई प्रश्न पूछे, और दूसरे भाग में उन्होंने उत्तरों को एकत्र किया और फिर से शुरू किया।

इसलिए, एरिक ने अपने ब्लॉग के पाठकों से सवाल पूछे:

भाषण का अंत

अनियंत्रित अपवादों के साथ जीवन

• क्या आपके कार्यक्रमों में बग थे जिन्हें आपने अपवाद हैंडलिंग द्वारा निर्धारित किया था जो आपको संदेह नहीं था, फेंकना संभव था?
• जब आप नए कोड लिखते हैं जो आपके द्वारा विकसित नहीं किए गए तरीकों को कॉल करते हैं, तो आपको कैसे पता चलेगा कि क्या अपवाद फेंके जा सकते हैं? क्या ऐसे अपवाद हैं जो आपको लगता है कि हमेशा किसी भी तरह से संभाला जाना चाहिए जो उन्हें फेंक देता है? उदाहरण के लिए, क्या यह सच है कि IOException
  
  
  
  को फेंकने वाली कोई भी विधि हमेशा try-catch
  
  
  
  में IOException
  
  
  
  जानी चाहिए?

भाषण देते हैं

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

भाषण का अंत



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

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

यह असभ्य है, लेकिन, मुझे लगता है, निष्पक्ष।

यह टिप्पणी पोकेमॉन प्रोसेसिंग को मानती है - उन सभी को पकड़ें! ( सभी को पकड़ना होगा ) समाधान है। मुझे आश्चर्य हुआ कि लगभग एक तिहाई टिप्पणीकारों ने catch(Exception)



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



दोनों कम से कम सही रास्ता और सबसे आसान है, तो इसका कारण यह है कि सही रास्ता बहुत भारी है।

टिप्पणीकारों के भारी बहुमत ने लिखा कि बग्स को ठीक किया गया था, जिसका कारण विशिष्ट प्रकार के अपवादों के लिए catch



की कमी थी, हालांकि ऐसे मामले अलग-अलग आवृत्ति वाले विभिन्न लोगों के साथ हुए: "1 से 2 बार", "कभी-कभी", "अक्सर" तक।

एक तीसरे ने कहा कि उन्होंने MSDN और अन्य प्रकार के प्रलेखन (XML टिप्पणियों सहित) का उपयोग उन अपवादों के प्रकारों को निर्धारित करने के लिए किया है जिन्हें पकड़ा जाना चाहिए। MSDN की प्रशंसा और आलोचना दोनों की गई थी; MSDN के कुछ भाग पूरी तरह से लिखे गए हैं, अन्य लिखे गए हैं ताकि कुछ भी स्पष्ट न हो। प्रलेखन के तीसरे भाग की पूरी तरह से आलोचना की गई थी, कोई भी इस तरह के प्रलेखन पर विश्वास नहीं करता है।

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

फिर, निराशा को निम्नलिखित टिप्पणी द्वारा संक्षेपित किया गया:

प्रत्येक try/catch



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

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

भाषण देते हैं

अचानक! लगभग हर चीज जो सीधे या परोक्ष रूप से सबसे अच्छी प्रैक्टिस बताई जाती है!

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

और आप catch(Exception)



से दूर नहीं जा सकते हैं: आपको हर जगह catch(Exception)



, और न केवल संदेश लूप स्तर पर, जब तक आपको नहीं लगता कि आपकी विशेष स्थिति में अपवादों को पूरे सिस्टम के माध्यम से उड़ने दें (आगे वे उड़ते हैं) (वे जितना अधिक संसाधन खाते हैं)।

catch(Exception)



साथ एक कैच रहता है: हम StackOverflow



या OutOfMemory



को पकड़ सकते हैं और यहां तक ​​कि हमारी आँखें भी नहीं ले सकते हैं, जिसके परिणामस्वरूप आपको दुःखद परिणाम मिलेंगे जिसके लिए आप लाखों रूबल (या डॉलर) का भुगतान कर सकते हैं यदि आप हैलो, वर्ल्ड नहीं लिखते हैं!

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

यहाँ एक साधारण स्थिर वर्ग है जो अपवाद हैंडलिंग को सरल बनाता है:

 public static class Exceptions { private static readonly List<Type> fatalExceptions = new List<Type> { typeof (OutOfMemoryException), typeof (StackOverflowException), //  ,        }; public static string FullMessage(this Exception ex) { var builder = new StringBuilder(); while (ex != null) { builder.AppendFormat("{0}{1}", ex, Environment.NewLine); ex = ex.InnerException; } return builder.ToString(); } public static void TryFilterCatch(Action tryAction, Func<Exception, bool> isRecoverPossible, Action handlerAction) { try { tryAction(); } catch (Exception ex) { if (!isRecoverPossible(ex)) throw; handlerAction(); } } public static void TryFilterCatch(Action tryAction, Func<Exception, bool> isRecoverPossible, Action<Exception> handlerAction) { try { tryAction(); } catch (Exception ex) { if (!isRecoverPossible(ex)) throw; handlerAction(ex); } } public static bool NotFatal(this Exception ex) { return fatalExceptions.All(curFatal => ex.GetType() != curFatal); } public static bool IsFatal(this Exception ex) { return !NotFatal(ex); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

उपयोग के उदाहरण:

 Exceptions.TryFilterCatch(host.Close, Exceptions.NotFatal, ex => logger.Error("    .", ex)); private bool TryGetTpmProcess(out Process process) { process = null; try { process = Process.GetProcessById(App.TpmProcessId.GetValueOrDefault()); return true; } catch (Exception ex) { if (ex.IsFatal()) throw; return false; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TryFilterCatch



विधि TryFilterCatch



एक छोटे रिकॉर्ड में फुटक्लॉथ को परिवर्तित करने की अनुमति देती है। एक्सटेंशन विधियों का उपयोग करना भी आसान है। TryFilterCatch



साथ विधि यहाँ जासूसी की ।



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



इसलिए, "बयान ग्रेनाइट में डाले गए" पर विश्वास न करें, दोनों को देखें और अपवादों को अपने आवेदन को मारने न दें।



भाषण का अंत