मुझे कोशिश-कैच के भीतर सभी विवरण क्यों लिखना चाहिए?

Question

मेरी कंपनी के प्रमुख का कहना है कि मुझे ट्राइ-कैच के स्टेटमेंट के भीतर सभी यानी मेरे सभी कोड को लिखना होगा। अब, मैं समझ सकता हूं कि 'सॉरी से बेहतर होना चाहिए' दृष्टिकोण।, लेकिन क्या यह सोचने के लिए भी चिकन-दिल नहीं है कि जब लेबल बनाया जाता है, तो फॉर्म की स्थिति निर्धारित होती है। ऐसे उदाहरण हैं जहां इस तरह के सरल ऑपरेशन में अपवाद हैं।

Comments

यह वही लोगों द्वारा चर्चा की तरह लगता है जो कहते हैं कि सभी SQL को बेहतर प्रदर्शन के लिए संग्रहीत प्रक्रियाओं के रूप में लिखा जाना चाहिए।

— Spong

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

— जेफ़ओ

@ जेफ ओ - मैं वास्तव में मानता हूं कि सॉफ्टवेयर विकास में प्रतिद्वंद्वी एक मालगाड़ी है।

— जॉरिस टिम्मरमन्स

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

— ब्रुक

अनुरोध का विषय अप्रासंगिक है ... सिर्फ यह कहना कि "मेरी कंपनी के प्रमुख का कहना है कि मुझे कोड करना चाहिए ..." एक बड़ा लाल झंडा है। यह micromanagement है ... यह उसका काम नहीं है।

— जोएलफैन

Answer 1

मेरी कंपनी के प्रमुख का कहना है कि मुझे ट्राइ-कैच के स्टेटमेंट के भीतर सभी यानी मेरे सभी कोड को लिखना होगा।

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

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

अपवाद हैंडलिंग वास्तव में बहुत सरल है:

अपवाद पकड़ो

• जब भी आपको अपवाद की प्रतिक्रिया के रूप में एक विशेष कार्रवाई की आवश्यकता होती है
• जब भी कोई अपवाद असंगत स्थिति में कार्यक्रम को छोड़ देगा, अगर अखंडित नहीं है

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

कई अपवादों को पहली जगह में भी नहीं फेंकना चाहिए, इसलिए अपवाद नियंत्रण के आसपास अपनी नियंत्रण संरचना का निर्माण न करें, बल्कि जब भी और जहां भी संभव हो अपवादों की संभावित घटना से बचने की कोशिश करें।

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

Comments

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

— ओलिवर वीलर

@ ओलिवर वेयलर: क्या आपके पास एक प्रशस्ति पत्र है जो बताता है कि हॉटस्पॉट संकलक क्या प्रयास / पकड़ने वाले ब्लॉक में नहीं करता है?

— कायप्रो द्वितीय

Answer 2

लेकिन यह सोचने के लिए भी चिकन-दिल नहीं है कि जब लेबल बनाया जाता है, तो फॉर्म की स्थिति निर्धारित होती है। ऐसे उदाहरण हैं जहां इस तरह के सरल ऑपरेशन में अपवाद हैं।

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

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

Comments

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

— जेफ़ओ

@ मिचेल बोर्गवर्ड: हे, इसलिए आपने मुझे नीचा दिखाया। आप इस सवाल पर नाराज हो गए और मेरे पोस्ट पर केवल डाउनवोट है। आपको अपने अहंकार या अपने आत्मसम्मान के साथ एक गंभीर समस्या लगती है। मैंने देखा कि अन्य quetsions पर भी। तुम्हें पता है, अन्य प्रोग्रामर के पास भी अच्छे उत्तर हैं।

— फाल्कन

@ फाल्कन: मैंने इस सवाल पर कुछ भी नहीं कहा। मेरे पास कोई विचार नहीं है जो आपको अन्यथा विश्वास करने के लिए प्रेरित करता है, लेकिन अगर किसी को गंभीर अहंकार की समस्या है, तो यह आप ही हैं।

— माइकल Borgwardt

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

— फाल्कन

Answer 3

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

यदि आप 100% निश्चित नहीं हो सकते हैं कि आप हर एक अपवाद को संभाल सकते हैं जो संभवतः पकड़ा जा सकता है, तो आप शायद कुछ सामान्य अपवाद हैंडलर लिखना बंद कर सकते हैं, इसमें प्रोग्राम के मुख्य लूप को लपेटते हुए - स्पष्ट रूप से कैसे करें के सटीक यांत्रिकी इस बात पर निर्भर करता है कि आप किस भाषा में काम कर रहे हैं। अपवाद के बारे में जितना हो सके, उतना विस्तार से लॉग इन करें, प्रोग्राम स्टेट ( उपयोगकर्ता के वर्तमान में काम करने वाले डेटा स्टोर के अलावा कहीं और - याद रखें, यह सब इस बिंदु पर दूषित हो सकता है ), और इसी तरह। फिर, अपवाद को फिर से उखाड़ फेंकें और ओएस को संभाल लें, हालांकि यह फिट दिखता है। इस कैच-ऑल अपवाद हैंडलर में, भयावह विफलता के लिए तैयार रहें। फिर, जब कार्यक्रम को फिर से शुरू किया जाता है, तो देखें कि क्या यह राज्य किसी भी तरह से उपयोगी है, और यदि यह है तो इसे बचाया जा सकता है; और संभवतः उपयोगकर्ता को एक बग रिपोर्ट आपको वापस भेजने की पेशकश करता है।

Comments

+1: कभी भी एक अपवाद को न पकड़ें यदि आप तुरंत इसे सही तरीके से नहीं निभा सकते हैं। (काश, कभी-कभी आपको इसे बस फिर से घूमने के लिए फँसाना पड़ता है, लेकिन एपीआई कुरकुरे के हिस्से के रूप में एक अलग प्रकार के रूप में टैग किया जाता है: मुझे इससे नफरत है।)

— डोनल फैलो

Answer 4

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

1. जोखिम होने की संभावना
2. इससे नुकसान हो सकता है

अब, यदि आप अपने घर से बाहर जाते हैं, तो एक पियानो आपके सिर पर गिरता है, जबकि ऐसा होने के लिए बहुत अवांछित है (शायद 0.001%), लेकिन आपको मार सकता है।

अपवाद हैंडलिंग ऐसा है। कोशिश करो ब्लॉक महंगा नहीं है। लेकिन पकड़ ब्लॉक वास्तव में महंगा है, क्योंकि इसे स्टैक ट्रेस की एक तालिका बनाने और अन्य सामान करने की आवश्यकता है। इसलिए कोशिश करें / ब्लॉक को पकड़ने के बारे में निर्णय लेने पर, आपको विचार करना चाहिए कि आपने कितनी बार संभवत: कैच ब्लॉक को हिट किया है। यदि 10,000 usages के बीच, आप केवल 1 बार इसे हिट करते हैं, तो इसका उपयोग करें। लेकिन अगर यह एक रूप है, और उपयोगकर्ता शायद इसे सही ढंग से 50% बार नहीं भरता है, तो आपको वहां एक कोशिश / कैच ब्लॉक डालने से बचना चाहिए।

उन स्थानों पर जहां अपवाद घटना की संभावना अधिक होती है, if {} else {}अपवाद अपवाद से बचने के लिए ब्लॉकों का उपयोग करने की सिफारिश की जाती है । उदाहरण के लिए, जहाँ आप लिखने के बजाय दो संख्याओं को विभाजित करना चाहते हैं:

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

आपको लिखना चाहिए:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

Comments

+1 "अपवादों" से निपटने के लिए / अन्यथा उपयोग करने के लिए जो मूल रूप से केवल आवेदन तर्क हैं।

— मॉर्गन हेरलॉकर

यदि यह उपयोगकर्ता से संबंधित है, तो याद रखें कि कंप्यूटर लोगों की तुलना में बड़े पैमाने पर तेज़ हैं। 50% फॉर्म सबमिशन में फेंका गया एक अपवाद अभी भी कई उपयोगकर्ताओं के साथ एक सेकंड में कुछ ही बार होने की संभावना है।

— डोनल फैलो

मैं कोशिश / पकड़ ब्लॉक के परिहार पर आपके साथ सहमत नहीं हूँ। लगातार अपवादों का अनुमान लगाने की कोशिश करना त्रुटिपूर्ण है, डेवलपर समय में महंगा है, और आपके कोड को पढ़ने के लिए कठिन बना देता है। एक लूप जो एक लाख अपवादों को फेंकता है और उन्हें पकड़ता है मेरी मशीन पर चलाने के लिए 500ms लेता है (बनाम एक खाली लूप के लिए 1ms), जो 99.99% मामलों (और सभी यूआई कोड) में वास्तविक-दुनिया का प्रदर्शन अंतर नहीं है। आपको उन मामलों को छोड़कर अपवादों का उपयोग करना चाहिए जहां आप प्रदर्शन के दंड संबंधी मामलों को जानते हैं, क्योंकि वे आपके कोड को अधिक विश्वसनीय बनाते हैं और आपको यह मान लेते हैं कि पिछले कोड को सफलतापूर्वक निष्पादित किया गया था।

— कायप्रो द्वितीय

@ cosmic.osmo, क्या आप स्टैकट्रेस को पुनः प्राप्त करते हैं या बस इसे पकड़ते हैं?

Answer 5

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

Comments

लॉग करने के लिए +1। जंगली में कार्यक्रम ब्लैक बॉक्स हैं। जब वे विफल होते हैं, तो एक लॉग यह कहते हुए कि "यहां वही हुआ जो" समस्या को हल करने के लिए बहुत लंबा रास्ता तय करता है। मेरे कार्यक्रमों में मेरी त्रुटियां हैं, जो बिना लाइसेंस के चले गए थे, और उन्हें लॉग में पाए जाने के बाद ही उन्हें उजागर किया गया था।

— एंड्रयू नीली

Answer 6

मैं व्यक्तिगत रूप से अपवादों को बर्दाश्त नहीं कर सकता, वे बहुत, बहुत, बहुत सही ढंग से संभाल रहे हैं। और भ्रष्ट डेटा को हटाने की कोशिश कर रहा है बहुत, बहुत, बहुत मुश्किल है!

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

यदि आप हर फ़ंक्शन को कॉल नहीं करते हैं जैसे:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

हर एग्जिट पॉइंट पर सही तरीके से सफाई करने का कोई तरीका नहीं है। अपवाद HARD हैं!

अपवादों के बारे में एकमात्र अच्छी बात यह है कि यदि आप उन्हें नहीं पकड़ते हैं, तो ऐप अप्रत्याशित व्यवहार पर क्रैश हो जाता है।