2011-12-19 16 views
18

मेरे पास नीचे दिखाए गए कुछ स्विच स्टेटमेंट हैं। ध्यान दें कि कोई ब्रेक नहीं है। Findbugs केवल दूसरे केस स्टेटमेंट पर त्रुटि रिपोर्ट कर रहा है। त्रुटि यह है: स्विच स्टेटमेंट पाया गया जहां एक मामला अगले मामले में आता है।ब्रेक के बिना स्विच

switch(x) { 

    case 0: 
     // code 

    case 1: 
     // code 

    case 2: 
     // code 
} 
+3

त्रुटि संदेश क्या कहता है? –

+9

और समस्या है ...? – fge

+0

क्या आप वाकई एक त्रुटि के बजाय चेतावनी नहीं हैं? – xagyg

उत्तर

2
को तोड़ने के बिना

वे एक दूसरे में हालांकि गिरावट इसलिए यदि x == 0 आप हर मामले बयान ब्लॉक में सभी कोड के माध्यम से जाना जाएगा होगा। Findbugs या तो त्रुटि के बारे में गलत हो सकता है, या ब्रेक के बिना यह त्रुटि स्थिति हो सकती है, यानी case 0 में कुछ तोड़ने के लिए case 1 में कुछ कारण बनता है।

सटीक कोड और त्रुटि के बिना मैं वास्तव में और मदद नहीं कर सकता। ब्रेक की कमी जानबूझकर है?

60

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

उदाहरण के लिए

तो:

switch (foo) { 
    case 0: 
     doSomething(); 
    case 1: 
     doSomethingElse(); 
    default: 
     doSomeOtherThing(); 
} 

यह पूरी तरह से वैध जावा है, लेकिन यह शायद क्या लेखक का इरादा नहीं करता है: यदि foo0 है, सभी तीन कार्यों काdoSomething, doSomethingElse, और doSomeOtherThing रन (उस क्रम में)। यदि foo1 है, केवल doSomethingElse और doSomeOtherThing रन। यदि foo कोई अन्य मूल्य है, तो केवल doSomeOtherThing रन।

इसके विपरीत:

switch (foo) { 
    case 0: 
     doSomething(); 
     break; 
    case 1: 
     doSomethingElse(); 
     break; 
    default: 
     doSomeOtherThing(); 
     break; 
} 

यहाँ, कार्यों में से केवल एक, चलेंगे foo के मूल्य पर निर्भर करता है।

यह एक आम कोडिंग त्रुटि break भूलना है के बाद से, FindBugs यह झंडा ऊपर आप के लिए जैसे उपकरण।

switch (foo) { 
    case 0: 
    case 1: 
     doSomething(); 
     break; 
    case 2: 
     doSomethingElse(); 
     break; 
    default: 
     doSomeOtherThing(); 
     break; 
} 

वहाँ, हम कॉल करने के लिए doSomething अगर foo0या1 है चाहता हूँ:

एक आम यूज-केस जहां कोई कोड हस्तक्षेप के साथ लगातार एक से अधिक case बयान है नहीं है। अधिकांश टूल इसे संभावित कोडिंग त्रुटि के रूप में फ़्लैग नहीं करेंगे, क्योंकि case 1 से पहले case 0 में कोई कोड नहीं है और यह एक काफी आम पैटर्न है।

+1

अंत में 'ब्रेक' वास्तव में आवश्यक है? – kcpr

+2

@kcpr: कड़ाई से बोलते हुए, आपको स्विच के अंतिम मामले (उपरोक्त में 'डिफ़ॉल्ट') पर 'ब्रेक' की आवश्यकता नहीं है। लेकिन मैं स्थिरता पसंद करते हैं। यह पूरी तरह से शैली का मामला है, वही बाइटकोड किसी भी तरह से बनाया जाता है। (यह निश्चित रूप से सच नहीं है यदि आप किसी भी * अन्य * 'ब्रेक को छोड़ देते हैं; '0) –

+0

यह सामान्य समस्या का एक बहुत अच्छा विवरण है और स्विच कैसे काम करता है, लेकिन वास्तव में ओपी के प्रश्न का उत्तर नहीं देता है - हालांकि, कड़ाई से बोलते हुए, ओपी वास्तव में एक प्रश्न प्रस्तुत नहीं किया था ... – Tasgall

3

स्विच गिरावट-थ्रू "कुशल कोड" के FindBugs श्रेणी में आते हैं। मुझे लगता है कि यह केवल त्रुटि संदेशों की संख्या को कम करने के लिए एक स्विच स्टेटमेंट में गिरावट के माध्यम से पहली घटना झंडेगा।

4

मैंने इन्हें टिप्पणियों के रूप में लिखा लेकिन फिर यह दिखाई नहीं दे रहा है। मैं उन्हें एक जवाब में बदल रहा हूँ। यह वास्तव में T.J.Crowder's answer का विस्तार है।

आप संबंधित नियम ढूंढ सकते हैं जो Findbugs को here त्रुटि की रिपोर्ट करने का कारण बनता है।

आप निम्न सामग्री के साथ एक XML फ़ाइल बनाकर इस प्रकार की त्रुटियों की रिपोर्ट करने के लिए Findbugs को रोक सकते हैं, filter.xml कहें और -exclude filter.xml विकल्प के साथ टूल चलाएं। filters on Findbugs देखें।

<FindBugsFilter> 
    <Match> 
    <Bug category="PERFORMANCE" /> 
    </Match> 
</FindBugsFilter> 
+0

स्टैक ओवरफ़्लो पर, यह उपयोगी जानकारी (जैसे उपरोक्त) जोड़ने के लिए किसी और के जवाब को संपादित करने के लिए वास्तव में स्वीकार्य है। इसका लाभ उठाएं! –

+1

@ टी.जे.क्रॉडर दुर्भाग्य से मेरे संपादन अस्वीकार कर दिए गए थे, मुझे अपना जवाब हटाना पड़ा। वैसे भी सुझाव के लिए धन्यवाद। – melihcelik

+0

मुझे संदेह है कि वास्तविक नियम अधिक सामान्य था ['SF_SWITCH_FALLTHROUGH'] (http: // findbugs।sourceforge.net/bugDescriptions.html#SF_SWITCH_FALLTHROUGH)। 'SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH' का अर्थ है," न केवल एक गिरावट थी, लेकिन यह पिछले कुछ मामलों में सहेजने की कोशिश की गई थी "। मेरी राय में, यह एक बग होने की अधिक संभावना है, इसलिए मैं 'FALLTHROUGH' नियम की तुलना में 'DEAD_STORE' नियम को अक्षम करने में अधिक संकोच करता हूं। –

2

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

अगर वहाँ एक तरह से विशेष रूप से FindBugs लेकिन Checkstyle उपकरण के साथ चेतावनी निष्क्रिय करने के लिए है विशेष टिप्पणी पहचान मैं नहीं जानता कि इस तरह के रूप /* fallthrough */ ग्रहण करने के लिए है कि उपयोगकर्ता वास्तव में निम्न कोड चाहता है निष्पादित किए जाने के लिए। इस तरह की टिप्पणी डालने से पठनीयता में भी सुधार होता है। http://checkstyle.sourceforge.net/config_coding.html#FallThrough

जावा कोड सम्मेलन भी fallthrough टिप्पणी के उपयोग का उल्लेख है। http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html

0

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

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