आप सी ++ अपवादों का उपयोग किस लिए करते हैं?

Question

शायद अपवाद सबसे विवादास्पद सी ++ सुविधा है। कई टीम including google उनका उपयोग नहीं करते हैं। निस्संदेह उनका उपयोग करने का निर्णय संदर्भ पर निर्भर करता है - उदाहरण के लिए, कुछ खेलों में आउट-ऑफ-मेमोरी पर क्रैश करना ठीक हो सकता है, लेकिन मेडिकल उपकरण नियंत्रण सॉफ्टवेयर में नहीं। आउट-ऑफ-मेमोरी के अलावा, कुछ टीमें नेटवर्क व्यवधान, फाइल-न पाए गए आदि के लिए अपवादों का उपयोग कर सकती हैं लेकिन अन्य लोग कह सकते हैं कि अपवाद कहा जाना आम बात है (अन्य लोग कह सकते हैं, लेकिन यदि यह आम है, तो क्या ?)

अक्सर अपवादों का उपयोग न करने का निर्णय संभवतः गुमराह तर्क पर आधारित है कि अपवाद-सुरक्षित कोड लिखना मुश्किल है। कुछ लोग कहते हैं कि तर्क गुमराह है क्योंकि त्रुटि कोड का उपयोग करने के विकल्प का उपयोग करने से कम से कम कठिन कोड होगा। डेविड अब्राहम clarifies इस बिंदु पर।

इस सवाल में, मैं जानने के लिए उत्सुक हूँ:

• क्या मामलों के लिए आप अपवाद प्रयोग करते हैं?
• आपके आवेदन का संदर्भ क्या है? आप अपवादों के बिना क्यों नहीं रह सकते?
• आप अपवाद-सुरक्षित कोड लिखने का प्रबंधन कैसे करते हैं? आपको निवेश का स्तर क्या है?
• क्या यह इसके लायक था?

Answer 1

मैं असाधारण व्यवहार के लिए अपवादों का उपयोग करता हूं, और अक्सर नहीं। जब डिबगिंग दुर्घटनाग्रस्त हो जाती है, तो मैं अक्सर ब्रेक-ऑन-अपवाद का उपयोग करता हूं, इसलिए यदि आपका कोड आमतौर पर होने वाली चीज़ों को संभालने के लिए अपवादों का उपयोग कर रहा है, तो मैं चुपचाप आप पर झुकाऊंगा। अप्रत्याशित तरीके से चीजें गलत होने पर उनका उपयोग करें।

स्वीकार्य उदाहरण: सर्वर पर आपका कोड निर्भर करता है अनुपलब्ध है, इसलिए आपकी सेवा कुछ भी सार्थक नहीं कर सकती है।

उदाहरण का अर्थ है कि मैं आपके कोड पर नाराज हूं: उपयोगकर्ता ने आपके फ़ंक्शन में इनपुट के रूप में 100 से अधिक संख्या दर्ज की है, जो < = 100 की अपेक्षा करता है।

वास्तव में, यदि आप उपयोगकर्ता के सामने वाले एप्लिकेशन पर काम कर रहे हैं, तो उपयोगकर्ता शायद अपवाद उत्पन्न करने वाले कुछ भी करने में सक्षम नहीं होना चाहिए।

यह बहुत ग्रे क्षेत्र है, इसलिए यदि आप सहमत/असहमत हैं तो मुझे ऊपर उठाने/डाउनवोट करने के लिए स्वतंत्र महसूस करें। यदि आप असहमत हैं तो कृपया एक टिप्पणी पोस्ट करें कि क्यों - मैं अन्य दिशानिर्देश/नियम/मीट्रिक सुनने के लिए उत्सुक हूं।

Answer 2

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

Answer 3

हालांकि बहुत से लोग वास्तव में 'कुछ असाधारण हुआ' के रूप में सी ++ में अपवादों का इलाज करते हैं, लेकिन मुझे बुनियादी त्रुटि-जांच/सत्यापन करने के लिए उन्हें बहुत ही आसान लगता है, ज्यादातर आवेदन-स्तर पर (जैसा कि मूल में नहीं है पुस्तकालय)

उदाहरण के लिए, मैं नहीं बल्कि

try 
{ 
    MethodA(); 
    MethodB(); 
    //.. a whole lot of other methods crucial to succeed for app initialization 
} 
catch(const SomeException& e) 
{ 
    //show user the critical error contained in e 
    return 1; 
} 

लिखते हैं तो लिख

if(!MethodA()) 
{ 
    //retrieve and show error 
    return 1; 
} 
if(!MethodB() || !MethodC()) 
{ 
    //retrieve and show error 
    return 1; 
} 
//etc 

यह कम कोड पर आधारित होते हैं, यह भी वीं के भीतर ई विधियों खुद।

Answer 4

मैं आम तौर पर असाधारण परिस्थितियों के लिए समर्थक अपवाद हूं, लेकिन शायद "असाधारण" क्या है, यह तय करने में मुझे सबसे अधिक बार है।

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

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

Answer 5

पिछली बार मैंने उन्हें इस्तेमाल किया:

फेंक "लगातार (उचित) त्रुटि संदेश"

जब एक गंभीर हालत का सामना।

वैश्विक चर में मैंने कुछ बार अतिरिक्त डेटा फंस लिया, लेकिन इससे पहले कि मैंने बहु थ्रेडेड कोड लिखा था। मुझे उस पर पुनर्विचार करना होगा (जाहिर है)।

नहीं कि मैं अब इस तकनीक की अनुशंसा करता हूं।

Answer 6

लगभग हर कोई लिखता है कि अपवाद फेंक सकता है। वे सभी मानक पुस्तकालयों में हैं। यह देखते हुए, मुझे नहीं लगता कि "कोई अपवाद नहीं" नीति एक अच्छी है।

मैं अपना खुद का अपवाद फेंकने वाला कोड नहीं लिखता, क्योंकि मैं उन चीजों से सीधे निपट नहीं पाता हूं जो गलत होने की संभावना है जैसे कि फेंकना उपयोगी होगा। अगर कुछ गंभीरता से गलत हो जाता है जहां इसे ठीक करने का कोई स्पष्ट तरीका नहीं है, तो फेंकना एक अच्छा विचार है।

मैं यह सुनिश्चित करने का प्रयास करता हूं कि जो कुछ मैं लिखता हूं वह अपवादों को फेंकने के मामले में अच्छी तरह से काम करेगा।