2009-07-21 9 views
5

क्या यह उन मामलों के प्रबंधन के लिए अपवाद का उपयोग करने का एक अच्छा अभ्यास है जो त्रुटियां नहीं हैं?गैर-त्रुटि उद्देश्यों के लिए अपवादों का उपयोग

जावास्क्रिप्ट और पायथन में जेनरेटर (उपज कीवर्ड) में स्टॉपइटरेशन केस का प्रबंधन करने की तरह।

+0

समुदाय विकी होना चाहिए। – SilentGhost

+0

स्पष्ट रूप से कोई जवाब निष्पादन प्रवाह को तोड़ने के लिए जावास्क्रिप्ट और पायथन के अपवादों के उपयोग को छूता है। –

उत्तर

8

यह भाषा पर निर्भर करता है। प्रत्येक भाषा में इसका अपना डिज़ाइन और मुहावरे हैं। अधिकांश भाषाओं के अपवादों के लिए असाधारण होना चाहिए।

सी ++, जावा और सी # जैसी भाषाओं में यह किसी भी चीज़ के लिए अपवादों का उपयोग करने के लिए बहुत खराब रूप है।

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

wikipedia लेख से

:

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

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

11

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

+4

कभी-कभी असाधारण और नियमित मामलों के बीच अंतर करना इतना आसान नहीं होता है। –

+0

एक उदाहरण देने के लिए देखभाल? – tomfanning

+0

@ सुओबोक मैं एक नुकसान में हूं जब भेद मुश्किल होगा। क्या आप नियमित मामले और असाधारण मामले के बीच लाइनों को धुंधला कर सकते हैं? –

10

आमतौर पर नहीं, नहीं। एएसपी.नेट Response.Redirect के लिए इसका उपयोग करता है - वास्तव में धागे को निरस्त करता है, फिर अपवाद को पकड़ता है और इसे रीसेट करता है। यह बहुत बुरा है, लेकिन यह आपको मूल रूप से अनुरोध के "स्तर" को छोड़ देता है, बिना किसी स्तर के ढेर के जागरूक होने के कारण उसे तुरंत लौटने की आवश्यकता होती है।

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

+1

शायद कभी-कभी अपवाद फेंकना स्पष्ट है कि बहुत से घोंसले 'वापसी' बयान? –

+0

@ सऊबोक: हम्म ... बहुत ही कम। ईमानदार होने के लिए यह एक सुंदर "असाधारण" स्थिति होगी। मैं वास्तव में सभी सामान्य परिस्थितियों में इसे टालने की कोशिश करता हूं। –

+0

डाउनवॉटर: एक कारण देने की देखभाल? –

3

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

2

सं

अपवाद केवल असाधारण परिस्थितियों के लिए इस्तेमाल किया जाना चाहिए (जैसा कि नाम से कहते हैं)। इसका मतलब है: त्रुटियां।

  • "उह, मुझे यह फ़ाइल नहीं मिल रही है।" - अपवाद!
  • "उह, मैं 0 से विभाजित नहीं कर सकता" - अपवाद!
  • "उह, मुझे कोई स्मृति नहीं मिल सकती है।" - अपवाद! , नंबर

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

+2

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

+0

आपके आवेदन के आंतों में गहराई यह अभी भी एक अपवाद है, बेशक आपको इसे उपयोगकर्ता को दिखाने से पहले इसे सुंदर बनाना होगा। – Bombe

1

जबकि स्वीकार करने असाधारण मामलों में एक प्रदर्शन हिट नहीं ले इस प्रकार एक -

  • "परिणाम 2.5 है।"!। अपवादों में से बहुत फेंके जाने/पकड़ा पारंपरिक निर्माणों की तुलना में धीमी हो जाएगा।

    यह भी विश्लेषण और कठिन कोड को समझने में आता है, और सबसे कोड रखरखाव में अपने समय के सबसे खर्च करता है।

  • +0

    बस ध्यान दें कि पाइथन और जावास्क्रिप्ट जनरेटर के अंत को प्रबंधित करने के लिए StopIteration अपवाद का उपयोग कर रहे हैं क्योंकि यह प्रत्येक पुनरावृत्ति पर एक विधि को कॉल करने से सस्ता है, यह जानने के लिए कि यह अंत है या नहीं। –

    +0

    "आम तौर पर" अपवाद (पन इरादा) हो सकता है। – Richard

    +1

    ... और वह प्लेटफार्म कार्यान्वयन विभिन्न नियमों पर काम कर सकता है (आखिरकार वे समाधान के अनुरूप मंच की गतिशीलता को संशोधित कर सकते हैं)। – Richard

    2

    यह एक बहुत ही क्ष है अपमानजनक अभ्यास। अगर आपको लगता है कि यह आपकी स्थिति के लिए सबसे अच्छी बात है, तो अपने WTF/m को नीचे रखने के लिए दस्तावेज़ को सुनिश्चित करना और टिप्पणी करना सुनिश्चित करें।

    1

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

    उदाहरण के लिए, मैं हाल ही में एक छोटे जावास्क्रिप्ट परीक्षण ढांचे का निर्माण करने की कोशिश की है, और मैं एक तरह से ढांचा उन कहने के लिए सक्षम होने के लिए के लिए चाहता था:

    skip(); 
    pending("pending message"); 
    fail("failure message"); 
    

    के बजाय:

    return skip(); 
    return pending("pending message"); 
    return fail("failure message"); 
    

    ये फ़ंक्शंस लाइब्रेरी फ़ंक्शन होंगे जो उदाहरण के लिए SkipTest अपवाद जैसे अपवाद फेंक देते हैं। उनका उपयोग करने के लिए एकमात्र अनुशंसित जगह टेस्ट विधियों के अंदर है। इन परीक्षण विधियों को हमेशा एक कोशिश/पकड़ ब्लॉक में निष्पादित किया जाता है जहां हर प्रकार के अपवाद का इलाज किया जाता है और, अपवाद के आधार पर ढांचा उचित कदम उठाता है।

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

    यहां एक छोटा उदाहरण है:

    $.it("should offer means to explicitly mark a spec as failed", function() { 
        $.fail("this spec must fail"); 
    }); 
    
    2

    एक सुडोकू solver मैंने लिखा में, एक अपवाद मामले में फेंक दिया जाता है पहेली हल है।

    मुख्य खोज फ़ंक्शन, एक निजी विधि, खुद को रिकर्सिव कॉल करके खोज पेड़ में उतरती है। सामान्य केस पहेली को हल करने में विफलता है, जिसके परिणामस्वरूप कॉलर को केवल सामान्य वापसी होती है; असाधारण केस पहेली को हल करने में सफलता है, इस मामले में हम सार्वजनिक विधि में पकड़ने के लिए सभी तरह से "फेंक (समाधान)" करते हैं।

    ऐसा कुछ कॉल/सीसी का उपयोग करके योजना में एक ज्ञात मुहावरे है। मैं अपने सी ++ कार्यक्रम में अनुकरण कर रहा था।

    मुझे इस दृष्टिकोण पर किसी के समर्थक या विचारों को सुनने में खुशी होगी।

    संबंधित मुद्दे