2010-11-24 18 views

उत्तर

11

यदि यह एक लाइब्रेरी फ़ंक्शन है, throw उचित कार्रवाई हो सकती है।

if (!condition1) { 
    throw "Condition 1 failed."; 
} 

if (!condition2) { 
    throw "Condition 2 failed."; 
} 

if (!condition3) { 
    throw "Condition 3 failed."; 
} 

// Superb! 

अन्य स्वीकार्य कार्रवाई हो सकती है:

  • 0, null, या undefined रिटर्निंग।
  • उपयोगकर्ता को एक त्रुटि प्रदर्शित करने और लौटने पर।

आपको यह निर्धारित करना होगा कि आपके उपयोग के मामले में कौन सी विफलता कार्रवाई सही है।

+0

अरे आप निंजा! 47 सेकंड? :-( – Dragontamer5788

+2

+1: "तीर सिर" नेस्टेड सशर्तों से पहले "अन्य" भाग की जांच करने के लिए शर्तों को परिवर्तित करके "अच्छा सिर" से बचने के लिए यह एक अच्छा अभ्यास है। त्रुटि जांच की एक रैखिक धारा को नेस्टेड से पढ़ने और समर्थन करना काफी आसान है सफलता की जांच की धारा – David

+2

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

0

क्या आप इसे पसंद करेंगे?

if (/* Condition 1*/ && /* Condition 2*/ && /* Condition 3 */) { 
    // Superb! 
} 
else if (! /* Condition 1*/){ 
    // Error 1 
} 
else if (! /* Condition 2*/){ 
    // Error 2 
} 
else if (! /* Condition 3*/){ 
    // Error 3 
} 
0
if (! /* Condition */) { 
Error 1 
throw someSortOfException 
} 

if (! condition 2){ 
Error 2 
throw someSortOfOtherException 
} 

if (! condition 3){ 
Error 3 
throw another Exception 
} 

// Success! 

स्थिति पर निर्भर करता है, अपने कोड पसंद हो सकता है। उदाहरण के लिए आप शायद उन अपवादों को कहीं पकड़ना चाहेंगे।

1

ठीक है आप अपवाद का उपयोग कर सकते हैं, या ब्लॉक के भीतर तोड़ सकते हैं, या कई फ़ंक्शन। कोड को सही तरीके से आदेश देने के लिए अक्सर इसकी शर्तों को बदलने की आवश्यकता होती है।

do { 
    if (! /* Condition 1 */) { 
     // Error 1 
     break; 
    } 

    if (! /* Condition 2 */) { 
     // Error 2 
     break; 
    } 

    if (! /* Condition 3 */) { 
     // Error 3 
     break; 
    } 

    // Superb! 
} while (false); 

do-, जबकि (गलत) पाश एक ब्लॉक है कि आप जिन भाषाओं में एक गुमनाम ब्लॉक को बर्दाश्त नहीं करेगा में से बाहर तोड़ सकते हैं बनाने का एक तरीका है। यह आसानी से एक समारोह हो सकता है और रिटर्न का उपयोग कर सकता है, या अपवादों के साथ प्रयास कर सकता है।

+0

और यह किसी और से बेहतर कैसे है? – M2tM

+1

@ एम 2 टीएम क्या मैंने कहा कि यह बेहतर था, मैंने कहा कि यह एक विकल्प था - मैंने दूसरों को सूचीबद्ध किया जो बेहतर थे और लोगों ने देखा नहीं था कि सबसे असामान्य दृष्टिकोण दिखाया। अन्य उत्तरों ने अन्य दृष्टिकोण दिखाए हैं। अगर-अन्य सेट डुप्लिकेट स्थितियों का उत्तर देता है जिसे मैं नापसंद करता हूं। – Orbling

+0

यह डुप्लिकेट स्थितियों का उत्तर नहीं देता है: यदि (! शर्त 1) {ERROR1} अन्यथा (! शर्त 2) {ERROR2} और यदि (! शर्त 3) {ERROR3} अन्य {SUCCESS} – M2tM

0
if (!condition1) 
    // Error 1 (and exit scope if necessary) 

if (!condition2) 
    // Error 2 (and exit scope if necessary) 

if (!condition3) 
    // Error 3 (and exit scope if necessary) 

// Superb! 
0

हां; आप अपने if कथन को एक ऑपरेटर का उपयोग करके एक एकल कंपाउंड स्टेटमेंट में एक साथ लिख सकते हैं, और एक ही ब्लॉक में त्रुटि शर्तों को संभाल सकते हैं। आपकी त्रुटि प्रबंधन आवश्यकताओं के आधार पर, आपको यह सुनिश्चित करने के लिए कि आप सही ढंग से त्रुटि को संभालने में सक्षम हैं, यह आपको कई if एस की आवश्यकता हो सकती है (यह वास्तव में आपके त्रुटि हैंडलिंग रिज़ॉल्यूशन पर निर्भर करता है)।

बुद्धि के लिए:

if (CondA && CondB && CondC) 
    { 
    // Execute success 
    } 
else 
    { 
    if (!CondA) 
     // Do error A 
    else if (!CondB) 
     // Do error B 
    else if (!CondC) 
    // Do error C 
    } 
} 
2

ऐसा लगता है कि जाँच करने के लिए 3 की स्थिति और 4 क्रिया (3 अलग त्रुटियों +1 सफलता) है। दुर्भाग्य से सामान्य मामले में इसे 3 सशर्त चेक और 4 कार्यों की आवश्यकता होगी। मुझे लगता है कि कोड निम्नलिखित संरचना का उपयोग करके थोड़ा साफ किया जा सकता है, हालांकि

if (! /* condition 1 */) { 
    // Error 1 
} else if (! /* condition 2 */) { 
    // Error 2 
} else if (! /* condition 3 */) { 
    // Error 3 
} else { 
    // superb 
} 
+0

एक अच्छी तरह से आदेशित फैशन में सामान्य भाषा संरचना का उपयोग कर त्रुटियों के बगल में स्थितियों को स्पष्ट रूप से ढेर करना। यह मेरे बाहर है क्यों इतने सारे लोग सोचते हैं कि फेंक दृष्टिकोण बेहतर है। – aaaaaaaaaaaa

+0

@e बिजनेस क्योंकि अगर कोई त्रुटि स्थिति है और यह एक फ़ंक्शन है, तो त्रुटि को फेंकना सही काम है। यदि तीन त्रुटि मामलों को कॉलर्स द्वारा अलग करने की आवश्यकता है, तो आपको या तो त्रुटि विवरण वाले कुछ ऑब्जेक्ट को वापस करना होगा (और इसलिए यह आवश्यक है कि इस परिदृश्य को कॉलर द्वारा परीक्षण किया जाए) या कोई त्रुटि फेंक दें। मुझे पता है कि मैं कौन सा पसंद करता हूं। – cdhowie

0

कुछ तरीके हैं, सबसे सरल बस कुछ कार्यों को खराब करने के लिए है और यह पता सार विभिन्न परतों (यह वैसे भी किया जाना चाहिए यदि आप पाते हैं अपने आप को गहरी जा रहा है।)

if (/* Condition */) { 
    value = aFunctionSaysWhat(); 
} else { 
    // value = Error 1 
} 

.... 
value aFunctionSaysWhat(){ 
    if (/* Condition */) { 
     return aSecondFunctionHere(); 
    } else { 
     // return Error 2 
    } 
} 

मूल आधार है कि एक समारोह अमूर्त यदि संभव हो तो से एक परत पर रहना चाहिए, और एक काम करते है।

अगली संभावना यह सब बाहर निकलना है, यह आपके प्रारंभिक नेस्टेड विधि से बेहतर है, लेकिन मूल रूप से समान जटिलता है। यदि आपके पास केवल कुछ विकल्प हैं और आप अधिक जोड़ने की योजना नहीं बनाते हैं तो यह कार्यात्मक दृष्टिकोण से अधिक क्लीनर हो सकता है।

if(ErrorCondition1){ 
    //Error 1 
}else if(ErrorCondition2){ 
    //Error 2 
}else if(ErrorCondition3){ 
    //Error 3 
}else{ 
    //Superb 
} 

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

Results = {'Result1':'Error1', 'Result2':'Error2', 'Result3':'Error3', 'Success':'Superb'} 

return Results[ConditionHash(Condition)]; 
संबंधित मुद्दे