2015-08-26 3 views
14

के लिए मामलों का उपयोग करें हाल ही में मैं कुछ पुस्तकालयों को C++ 11 में <system_error> सुविधाओं का उपयोग करने के लिए परिवर्तित कर रहा हूं।std :: error_code

मुझे std::error_code बनाम std::error_condition के उपयोग के मामलों को समझने में कठिनाई हो रही है।

नोट, मैं अंतर को समझता हूं - many questions on stackoverflow हैं जो अंतर पर जाते हैं।

मूल अंतर यह है कि std::error_code को सिस्टम-या प्लेटफ़ॉर्म-विशिष्ट त्रुटि का प्रतिनिधित्व करना चाहिए, जबकि std::error_condition एक सार त्रुटि है जो एक API या उपयोगकर्ता इंटरफ़ेस वापस आना चाहिए।

ठीक है - लेकिन मुझे समझ में समस्या आ रही है कि हम कभी भी अभ्यास में std::error_code का उपयोग क्यों करेंगे। मुझे ऐसा लगता है कि आप या तो जा रहे हैं करने के लिए:

  1. एक प्रणाली विशिष्ट त्रुटि रिपोर्टिंग तंत्र के साथ साथ getsockopt के लिए एक कॉल निपटने (जैसे , कहते हैं कि errno या कुछ और एक POSIX कॉल से लौटे, या कहते हैं, हो सकता है लिनक्स पर SO_ERROR) जो आप आसानी से std::error_condition पर std::errc एनम्स के माध्यम से परिवर्तित कर सकते हैं, जिन्हें पोर्टेबल माना जाता है। जो भी std::error_condition के लिए एक उपयोग मामला होगा -

  2. त्रुटियों की एक प्रयोक्ता परिभाषित श्रेणी है, जो अनुप्रयोग स्तर या व्यापार-तर्क त्रुटियों का प्रतिनिधित्व, जैसे "अवैध सामाजिक सुरक्षा नंबर" या जो कुछ का उपयोग किया।

  3. कुछ निम्न-स्तरीय इंटरफ़ेस या लाइब्रेरी से निपटें जो ओपनएसएसएल जैसी अपनी त्रुटि रिपोर्टिंग तंत्र को परिभाषित करता है, इस स्थिति में आप सीधे प्लेटफ़ॉर्म-विशिष्ट त्रुटि तंत्र का उपयोग करेंगे। इस मामले में आपको इन त्रुटियों को std::error_code में कनवर्ट या मैप करने की आवश्यकता होगी। लेकिन यदि आप इन प्लेटफ़ॉर्म विशिष्ट त्रुटियों को std::error_code जैसी सामान्य चीज़ों में परिवर्तित करने की परेशानी से गुजरने जा रहे हैं, तो क्यों न केवल std::error_condition पर परिवर्तित करें?

इसके अतिरिक्त, क्योंकि POSIX प्रणाली त्रुटियों पोर्टेबल होना चाहिए रहे हैं, और के बाद से वे std::errc enum के माध्यम से std::error_condition के साथ एक-से-एक नक्शा, मैं std::error_code के लिए किसी भी उपयोग के मामले नहीं मिल रहा। अधिकांश लिनक्स/यूनिक्स सिस्टम कॉल errno सेट करता है, जिसे पोर्टेबल रूप से std::error_condition पर मैप करना चाहिए।

तो, मुझे कहीं भी std::error_code के लिए कोई उपयोग केस नहीं दिख रहा है। तो, कुछ उदाहरण उदाहरण क्या हैं जहां हम std::error_condition के बजाय std::error_code का उपयोग करना चाहते हैं?

+0

के बारे में क्या [इस] (http://stackoverflow.com/a/16687434/560648) स्पष्ट नहीं है? –

+0

@ लाइटनेसरेसेसिन ऑर्बिट, विचार स्पष्ट है - लेकिन मुझे अभ्यास में 'error_code' का उपयोग नहीं दिख रहा है। आपके द्वारा प्रदान किया गया लिंक कहता है: "प्रत्येक' std :: error_code' ऑब्जेक्ट में ऑपरेटिंग सिस्टम, या कुछ निम्न-स्तरीय इंटरफ़ेस से उत्पन्न त्रुटि कोड की एक जोड़ी होती है "- ठीक है, लेकिन ऑपरेटिंग सिस्टम या तो आपको एक POSIX त्रुटि देगा (जो पोर्टेबल है और इसे आसानी से 'std :: error_condition' में परिवर्तित किया जा सकता है) या किसी अन्य प्रकार की निम्न-स्तरीय त्रुटि (जैसे मुझे लगता है कि Win32 त्रुटि, उदाहरण के लिए), जिसे आपको मैन्युअल रूप से 'std :: error_code' - लेकिन त्रुटि_code पर मैपिंग का उपयोग क्या है? ... – Siler

+0

... यदि आपको कुछ प्लेटफार्म विशिष्ट करने की ज़रूरत है, तो आप सीधे मंच सुविधाओं के साथ काम करते हैं। यदि आपको त्रुटि को और अधिक सामान्य में कनवर्ट करने की आवश्यकता है, तो आप error_condition का उपयोग करते हैं। मैं बस यह नहीं देखता कि error_code इनमें से किसी भी में फिट बैठता है। – Siler

उत्तर

13

मैं उस समय के बारे में सोच रहा था और जवाब here मिला। अनिवार्य रूप से, error_code त्रुटि कोड को संग्रहीत और परिवहन करने के लिए उपयोग किया जाता है, जबकि error_condition त्रुटि कोड से मेल खाने के लिए उपयोग किया जाता है।

void handle_error(error_code code) { 
    if  (code == error_condition1) do_something(); 
    else if(code == error_condition2) do_something_else(); 
    else        do_yet_another_thing(); 
} 

प्रत्येक error_condition अलग error_categories से संभवतः error_code का एक सेट करने के लिए बराबर है। इस तरह आप किसी निश्चित प्रकार की सभी त्रुटियों का इलाज कर सकते हैं, इससे कोई फर्क नहीं पड़ता कि वे किस उपप्रणाली से उत्पन्न होते हैं।

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

श्रेणियों द्वारा समकक्षता को परिभाषित किया गया है; यदि error_code की श्रेणी error_condition बराबर, या समझता है error_condition की श्रेणी error_code बराबर है, तो operator== रिटर्न error_condition और error_code की है कि जोड़ी के लिए true समझता है। इस तरह आप अपनी खुद की त्रुटि श्रेणी से error_code एस प्राप्त कर सकते हैं और उन्हें कुछ सामान्य या सिस्टम error_condition एस के बराबर बना सकते हैं।

+2

मैं स्पष्ट करता हूं कि लाइब्रेरी को 'error_code' के साथ त्रुटियों को सिग्नल करना चाहिए और उन्हें मिलान करने के लिए मानक' error_condition' enums घोषित करना या पुन: उपयोग करना चाहिए। इस तरह किसी त्रुटि के बारे में पूरी जानकारी पास हो जाती है और ऐसी लाइब्रेरी का उपयोगकर्ता इसे लॉग या प्रिंट कर सकता है। लेकिन ऊपरी कार्यक्रम तर्क से अतिरिक्त विवरण छुपाए गए हैं। –

+0

स्पष्टीकरण के साथ सहमत हैं। यह भी सुझाव देता है कि एपीआई को 'error_code' को गैर-हानिकारक वास्तविक त्रुटि-मान के रूप में प्रचारित करना पसंद करना चाहिए, जहां किसी ऑपरेशन के कोड परीक्षण परिणामों को 'error_condition' में अंतर्निहित रूपांतरण होना चाहिए, जहां अतिरिक्त श्रेणियों को संकुचित और कनवर्ट करने के लिए परिभाषित किया जा सकता है- मंच-स्वतंत्र विफलता परिदृश्यों के लिए विशिष्ट त्रुटि-मान। – charley

0

this blog को शामिल किया गया है कि तुम क्या

की जरूरत है और आप भी पढ़ सकते हैं इस "Your own error code"

+0

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

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