2011-10-11 29 views
6

मेरे पास एक नियंत्रण सर्किट है जिसे मैं सीरियल पोर्ट के माध्यम से संवाद करता हूं। यदि प्रतिक्रिया कमांड किसी निश्चित प्रारूप से मेल नहीं खाता है तो मैं इसे एक त्रुटि मानता हूं और सोच रहा था कि मुझे त्रुटि कोड वापस करना चाहिए या अपवाद फेंकना चाहिए? उदाहरण के लिए:सी # त्रुटि कोड बनाम अपवाद

public double GetSensorValue(int sensorNumber) 
{ 
    ... 
    string circuitCommand = "GSV,01," + sensorNumber.ToString(); // Get measurement command for specified sensor. 
    string responseCommand; 
    string expectedResponseCommand = "GSV,01,1,OK"; 
    string errorResponseCommand = "ER,GSV,01,1,62"; 

    responseCommand = SendReceive(circuitCommand); // Send command to circuit and get response. 

    if(responseCommand != expectedResponseCommand) // Some type of error... 
    { 
     if(responseCommand == errorResponseCommand) // The circuit reported an error... 
     { 
     ... // How should I handle this? Return an error code (e.g. -99999) or thrown an exception? 
     } 
     else // Some unknown error occurred... 
     { 
     ... // Same question as above "if". 
     } 
    } 
    else // Everything is OK, proceed as normal. 
     ... 
} 

धन्यवाद!

उत्तर

8

में लगभग सभी मामले मैं अपवादों के माध्यम से त्रुटियों को संवाद करता। मैं लगभग कभी भी "त्रुटि कोड" का उपयोग नहीं करता - कभी-कभी int.TryParse आदि के परिणामस्वरूप सफलता/विफलता देने के लिए उपयोगी होता है, लेकिन मुझे नहीं लगता कि यह स्थिति इस तरह काम करती है। यह वास्तविक त्रुटि स्थिति की तरह लगता है जो आगे की प्रगति को रोकना चाहिए, इसलिए अपवाद उचित है।

संपादित करें: टिप्पणियों में नोट किया गया है, यदि सर्किट रिपोर्टिंग एक त्रुटि वास्तव में "अपेक्षित" है और कॉलर इसके साथ सौदा करने में सक्षम होना चाहिए और सक्रिय रूप से उस स्थिति की तलाश करनी चाहिए, तो स्थिति कोड का उपयोग करना उचित है।

दुर्भाग्य त्रुटि हैंडलिंग उन चीजों है कि हम वास्तव में सही अभी तक सॉफ्टवेयर इंजीनियरिंग में मिला नहीं किया है में से एक है ...

+0

दिलचस्प; मुझे आश्चर्य है कि आप मानक त्रुटि हैंडलिंग के लिए अपवादों की अनुशंसा करेंगे। क्या आप असामान्य या अप्रत्याशित परिस्थितियों के लिए अपवाद सुरक्षित नहीं करेंगे? –

+0

@ जॉन वेल्डन: नहीं, मैं उन त्रुटियों के लिए उनका उपयोग करूंगा जिसका मतलब है कि कॉलिंग कोड केवल आगे बढ़ना नहीं चाहिए जैसे सबकुछ ठीक था। ऐसा लगता है कि यह * एक अनपेक्षित स्थिति है हालांकि: "अगर प्रतिक्रिया कमांड किसी निश्चित प्रारूप से मेल नहीं खाता है तो मुझे लगता है कि यह एक त्रुटि है।" –

+0

यानी।कार्यक्रम का सामान्य प्रवाह इस मामले को संभालने का इरादा नहीं है? मैं उस मामले में अपवादों के उपयोग से सहमत हूं। हालांकि, अगर कार्यक्रम को सामान्य रूप से इस त्रुटि की स्थिति का जवाब देने की उम्मीद करनी चाहिए तो मैं अपवादों का उपयोग नहीं करूंगा। प्रश्न की मेरी व्याख्या उत्तरार्द्ध थी, लेकिन पूर्व समान रूप से व्यवहार्य होगा। –

2

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

3

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

तो यह मेरे थे मैं शायद पहले मामले में एक त्रुटि कोड (ज्ञात त्रुटि प्रतिक्रिया) वापसी चाहते हैं, और दूसरे मामले में एक अपवाद (अज्ञात त्रुटि कोड)

+0

+1 "अप्रत्याशित होने की अपेक्षा करें" - बीमा होने की तरह (= try + catch) मुझे किसी ऐसे व्यक्ति (= फेंक अपवाद) में ड्राइव करने नहीं देता है जो ड्राइविंग नियमों का सम्मान नहीं करता है बाद में यह पता लगाने के लिए कि बीमा कंपनी ने नहीं किया क्या आवश्यक है (अपवाद संभाल लें)। – Arun

2

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

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

class DeviceResult //could also be struct 
{ 
    public double ReturnValue { get; set; } 
    public bool IsValid { get; set; } 
    public string ErrorMessage { get; set; } 
} 

बारीकियों यहाँ वास्तव में महत्वपूर्ण नहीं हैं: तो, मैं की तरह कुछ परिभाषित करते हैं। इस उदाहरण में, क्लाइंट एपीआई वैध जांचना होगा और यदि ऐसा है, तो वापसी मूल्य का उपयोग करें - कोई जादू संख्या नहीं और कोई अपवाद नहीं। प्रतिमान अधिक महत्वपूर्ण है। जिस तरह से मैं इसे देखता हूं, आप ऑब्जेक्ट उन्मुख भाषा का उपयोग कर रहे हैं - ताकि आप वस्तुओं का भी उपयोग कर सकें। :)

+0

संयोग से, यदि आपके डिवाइस एपीआई से कई अलग-अलग रिटर्न प्रकार हैं, तो आप डिवाइस रीसेट को परिभाषित कर सकते हैं जिसमें रिटर्न वैल्यू "टी" है –

0

त्रुटि कोड।

  1. अपवाद फेंकने मूल्यों को वापस करने से धीमे काम करता है।
  2. आप विधि हस्ताक्षर को डिज़ाइन करने के लिए स्वतंत्र हैं, इसलिए आप जो भी प्रकार चाहते हैं उसे वापस कर सकते हैं। अगर आपको कुछ विशिष्ट प्रकार वापस करना पड़ा जो सार्थक तरीके से विस्तारित नहीं किया जा सका, तो आपको निश्चित रूप से अपवाद फेंकना पड़ा।
  3. किसी विधि का आह्वान करते समय त्रुटि कोड से अपवादों को अनदेखा करना आसान है। आपको उन अपवादों को दस्तावेज करना होगा जिन्हें आपकी विधि फेंक रही है और उम्मीद है कि अन्य डेवलपर इसे पढ़ लेंगे।
  4. GetSensorValue विधि की प्रतिक्रिया के अलग-अलग पथ हैं। "खुश पथ" स्पष्ट रूप से अपेक्षित और सबसे दिलचस्प है। लेकिन यदि आप जानते हैं कि उपभोक्ता कम हापी पथों के परिणाम संभाल सकते हैं, तो त्रुटि कोड के साथ जाने का अर्थ यह है कि "दुखी पथ" प्रतिक्रिया अधिक अपेक्षित है।
  5. कई अपवादों को फेंकने से आपके डीबगर अपवाद सेटिंग्स के आधार पर आपके डीबगर लगातार टूटने का कारण बन सकता है।
  6. रिटर्निंग त्रुटि कोड निश्चित रूप से आपके प्रतिक्रिया प्रकार को अधिक जटिल बना देंगे, जिसके लिए मूल्य को अनचाहे करने के लिए अधिक कोड की आवश्यकता होगी। लेकिन क्या यह पढ़ना और लिखना वाकई मुश्किल है "अगर (प्रतिक्रिया। स्थिति == स्थितिएं। असफल) {var value = respond.Value;}" कोशिश करने की बजाय?

जब यह अपवाद फेंकने के लिए एक अच्छा अभ्यास है:

  1. आप अनुमान कर सकते हैं जब कि अपने विधि मंगलाचरण असफल हो जायेगी (यदि आप इसे प्रदर्शन से पहले एक ऑपरेशन प्रदर्शन कर सकते हैं की जाँच)। एक त्रुटि कोड भी वापस करने के लिए "प्रदर्शन" विधि लागू की जा सकती है, लेकिन यह चेक-प्रदर्शन विधियों को एक पैटर्न माना जाता है।
  2. आप एक सार्थक तरीके से प्रतिक्रिया प्रकार का विस्तार नहीं कर सकते हैं, लेकिन आपको उस स्थिति में एक प्रतिक्रिया को संकेत देने की आवश्यकता है जो विधि के अनुबंध से पूर्ववत नहीं था।
  3. पिछले की तरह, आपके पास केवल "खुश पथ" परिणाम लौटने के अच्छे कारण हैं।
0

मैं कुछ सरल तथ्यों की वजह से ज्यादातर मामलों में अपवाद का उपयोग कर की सिफारिश करेंगे:

  1. अपवाद वैश्विक हैं, सभी सी # -developers जानता है क्या एक अपवाद है (और उम्मीद है कि) कैसे डीबगिंग के लिए इसका इस्तेमाल करने के ।
  2. अपवाद "कॉलिंग कैच" के लिए सभी कॉलिंग विधियों से बाहर निकलता है। यदि मेरे पास कई परतें हैं और अंदरूनी परत एक अपवाद फेंकता है तो मैं उस अपवाद को जो भी परत चाहता हूं (आमतौर पर बाहरी या दूसरी बाहरी परत) में संभाल सकता हूं।
  3. अधिकांश प्रोजेक्ट प्रकारों में कुछ प्रकार की अतिरंजित विधि या घटना होती है जिसे सरल वैश्विक अपवाद कोड लागू करने के लिए ओवरराइड/सब्सक्राइब किया जा सकता है। यह त्रुटि संदेशों को प्रारूपित करना, लॉगिंग करना, मेल भेजना और देवताओं से प्रार्थना करना आसान बनाता है (या अपवादों को संभालने पर आप जो कुछ भी करते हैं;))।

    1. यह एक अपवाद फेंक करने के लिए स्वतंत्र नहीं है:

    कुछ चीजें हालांकि विचार करने के लिए कर रहे हैं। यदि आपके कोड को 100% अनुकूलित करने की आवश्यकता है तो अपवाद फेंकना कुछ ऐसा हो सकता है जिसे आप टालना चाहते हैं।

  4. अपवादों में बहुत सारी जानकारी है जिनकी आपको आवश्यकता नहीं हो सकती है। क्या आपको वास्तव में एक स्टैकट्रैक चाहिए यदि आप ऐसा करना चाहते हैं तो उपयोगकर्ता को एक साधारण त्रुटि संदेश दिखाना है?

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

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