🧓🏾 🗣️ 💒 भविष्य के "C ++" में नियतात्मक अपवाद और त्रुटि से निपटने 🤣 🧑🏾 👎🏾

यह अजीब बात है कि हब्रत पर अभी तक C ++ मानक के लिए एक "ज़ीरो-ओवरहेड निर्धारक अपवाद" नामक प्रस्ताव का कोई उल्लेख नहीं था। इस कष्टप्रद चूक को सुधारना।

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

नीचे चर्चा न केवल स्थैतिक अपवादों के बारे में, बल्कि मानक से संबंधित प्रस्तावों के बारे में, और त्रुटियों को संभालने के अन्य सभी तरीकों के बारे में भी आयोजित की जाएगी। यदि आप यहाँ सिंटैक्स को देखने के लिए गए हैं, तो यहाँ यह है:

double safe_divide(int x, int y) throws(arithmetic_error) { if (y == 0) { throw arithmetic_error::divide_by_zero; } else { return as_double(x) / y; } } void caller() noexcept { try { cout << safe_divide(5, 2); } catch (arithmetic_error e) { cout << e; } }

यदि विशिष्ट प्रकार की त्रुटि महत्वहीन / अज्ञात है, तो आप केवल throws और catch (std::error e) उपयोग कर सकते हैं।

जानकर अच्छा लगा

`std::optional` और `std::expected`

आइए हम तय करें कि फ़ंक्शन में संभावित रूप से उत्पन्न होने वाली त्रुटि "घातक" नहीं है जो इसके अपवाद को फेंकने के लिए पर्याप्त है। परंपरागत रूप से, त्रुटि जानकारी एक आउट पैरामीटर का उपयोग करके वापस की जाती है। उदाहरण के लिए, फाइलसिस्टम टीएस कई समान सुविधाएँ प्रदान करता है:

 uintmax_t file_size(const path& p, error_code& ec);

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

पिछले कुछ समय से, बूस्ट ऐसी "गैर-घातक" त्रुटियों से निपटने के लिए एक सुरुचिपूर्ण समाधान की पेशकश कर रहा है, जो कुछ निश्चित परिदृश्यों में सही कार्यक्रम में सैकड़ों द्वारा हो सकता है:

 expected<uintmax_t, error_code> file_size(const path& p);

expected प्रकार variant समान है, लेकिन यह "परिणाम" और "त्रुटि" के साथ काम करने के लिए एक सुविधाजनक इंटरफ़ेस प्रदान करता है। डिफ़ॉल्ट रूप से, expected परिणाम expected में संग्रहीत होता expected । file_size कार्यान्वयन कुछ इस तरह दिख सकता है:

 file_info* info = read_file_info(p); if (info != null) { uintmax_t size = info->size; return size; // <== } else { error_code error = get_error(); return std::unexpected(error); // <== }

यदि त्रुटि का कारण हमारे लिए दिलचस्प नहीं है, या त्रुटि केवल परिणाम की "अनुपस्थिति" में शामिल हो सकती है, तो optional उपयोग किया जा सकता है:

 optional<int> parse_int(const std::string& s); optional<U> get_or_null(map<T, U> m, const T& key);

बूस्ट से सी ++ 17 में, वैकल्पिक एसटीडी आया ( optional<T&> लिए समर्थन के बिना); C ++ 20 में, वे अपेक्षित जोड़ सकते हैं (यह केवल प्रस्ताव है, सुधार के लिए धन्यवाद RamzesXI )।

संविदा

कॉन्ट्रैक्ट्स (अवधारणाओं के साथ भ्रमित नहीं होना) फ़ंक्शन मापदंडों पर प्रतिबंध लगाने का एक नया तरीका है, C ++ 20 में जोड़ा गया है। 3 एनोटेशन जोड़े गए:

समारोह मापदंडों की जाँच करता है
सुनिश्चित करता है कि फ़ंक्शन का रिटर्न मान चेक किया जाए (इसे एक तर्क के रूप में लिया जाता है)
मुखर - मैक्रो मुखर के लिए एक सभ्य प्रतिस्थापन

 double unsafe_at(vector<T> v, size_t i) [[expects: i < v.size()]]; double sqrt(double x) [[expects: x >= 0]] [[ensures ret: ret >= 0]]; value fetch_single(key e) { vector<value> result = fetch(vector<key>{e}); [[assert result.size() == 1]]; return v[0]; }

आप अनुबंध के उल्लंघन के लिए कॉन्फ़िगर कर सकते हैं:

जिसे अविभाजित व्यवहार कहा जाता है, या
इसने उपयोगकर्ता को बाहर निकलने की जाँच की और बुलाया, जिसके बाद std::terminate

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

std :: error_code

C ++ 11 में जोड़ा गया <system_error> लाइब्रेरी, आपको अपने प्रोग्राम में त्रुटि कोड से निपटने के मानकीकरण की अनुमति देता है। std :: error_code में टाइप वंश के त्रुटि कोड और कुछ वंशज वर्ग के ऑब्जेक्ट के लिए एक पॉइंटर शामिल होता है :: error_category । यह ऑब्जेक्ट, वास्तव में, वर्चुअल फ़ंक्शंस की तालिका की भूमिका निभाता है और दिए गए std::error_code के व्यवहार को निर्धारित करता है।

अपना std::error_code बनाने के लिए, आपको अपने std::error_category वंशज std::error_category को परिभाषित करना होगा और आभासी तरीकों को लागू करना होगा, जिनमें से सबसे महत्वपूर्ण है:

 virtual std::string message(int c) const = 0;

आपको अपने std::error_category लिए एक वैश्विक चर भी बनाना होगा। एरर_कोड + अपेक्षित का उपयोग करते हुए त्रुटि को कुछ इस तरह से देखता है:

 template <typename T> using result = expected<T, std::error_code>; my::file_handle open_internal(const std::string& name, int& error); auto open_file(const std::string& name) -> result<my::file> { int raw_error = 0; my::file_handle maybe_result = open_internal(name, &raw_error); std::error_code error{raw_error, my::filesystem_error}; if (error) { return unexpected{error}; } else { return my::file{maybe_result}; } }

यह महत्वपूर्ण है कि std::error_code 0 का मान कोई त्रुटि नहीं है। यदि यह आपकी त्रुटि कोड के लिए मामला नहीं है, तो इससे पहले कि आप सिस्टम त्रुटि कोड को std::error_code परिवर्तित करें, आपको कोड 0 को SUCCESS और इसके विपरीत बदलना होगा।

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

विनाशकारी चाल / तुच्छ स्थान

आपको वस्तुओं का एक और वर्ग बनाने की आवश्यकता है जो कुछ संसाधनों का मालिक है। सबसे अधिक संभावना है, आप इसे गैर-प्रतिलिपि बनाने योग्य बनाना चाहते हैं, लेकिन जंगम, क्योंकि यह असम्बद्ध वस्तुओं के साथ काम करने के लिए असुविधाजनक है (सी ++ 17 से पहले उन्हें एक समारोह से वापस नहीं किया जा सकता है)।

लेकिन यहाँ मुसीबत है: किसी भी मामले में, हटाए गए ऑब्जेक्ट को हटाने की आवश्यकता है। इसलिए, "स्थानांतरित-से" की एक विशेष स्थिति आवश्यक है, अर्थात्, "खाली" वस्तु जो कुछ भी नहीं हटाती है। यह पता चला है कि प्रत्येक सी ++ वर्ग में एक खाली राज्य होना चाहिए, अर्थात, निर्माणकर्ता से विध्वंसक तक शुद्धता की एक अपरिवर्तनीय (गारंटी) के साथ एक वर्ग बनाना असंभव है। उदाहरण के लिए, किसी फ़ाइल की सही open_file श्रेणी बनाना संभव नहीं है जो उसके जीवन भर में खुली हो। यह उन कुछ भाषाओं में से एक को देखने के लिए अजीब है जो सक्रिय रूप से RAII का उपयोग करते हैं।

एक और समस्या पुरानी वस्तुओं की ज़ीरोइंग है जब चलती है एक ओवरहेड जोड़ता है: std::vector<std::unique_ptr<T>> भरना std::vector<std::unique_ptr<T>> std::vector<T*> की तुलना में 2 गुना धीमा हो सकता है std::vector<T*> पुराने std::vector<std::unique_ptr<T>> के ढेर के कारण जब चलती है , डमी को हटाने के बाद।

सी ++ डेवलपर्स ने लंबे समय तक जंग पर पाला है, जहां विध्वंसक को स्थानांतरित वस्तुओं पर नहीं बुलाया जाता है। इस सुविधा को विनाशकारी चाल कहा जाता है। दुर्भाग्य से, प्रस्ताव सामान्य रूप से स्थानांतरित करने योग्य प्रस्ताव C ++ में जोड़ने की पेशकश नहीं करता है। लेकिन ओवरहेड समस्या हल हो जाएगी।

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

निम्नलिखित प्रकार की स्थितियों में से एक सही होने पर एक प्रकार के त्रैमासिक बिंदु से एक प्रकार का त्रैमासिक संबंध है:

यह तुच्छ रूप से जंगम + तुच्छ विनाशकारी है (उदाहरण int या POD संरचना)
यह [[trivially_relocatable]] विशेषता के साथ चिह्नित वर्ग है [[trivially_relocatable]]
यह एक ऐसा वर्ग है जिसके सभी सदस्य त्रैमासिक रूप से स्थानांतरित होते हैं।

आप इस जानकारी का उपयोग std::uninitialized_relocate साथ कर सकते हैं, जो सामान्य तरीके से मूव इनिट + डिलीट को निष्पादित करता है, या यदि संभव हो तो त्वरित किया जाता है। यह [[trivially_relocatable]] मानक पुस्तकालय के अधिकांश प्रकारों को चिह्नित करने का सुझाव दिया गया है, जिसमें std::string , std::vector , std::unique_ptr । ओवरहेड std::vector<std::unique_ptr<T>> ध्यान में रखते हुए प्रस्ताव गायब हो जाएगा।

अब अपवादों में क्या गलत है?

सी ++ अपवाद तंत्र 1992 में विकसित किया गया था। विभिन्न कार्यान्वयन विकल्प प्रस्तावित किए गए हैं। इनमें से, एक अपवाद तालिका तंत्र का चयन किया गया था जो कार्यक्रम निष्पादन के मुख्य पथ के लिए ओवरहेड की अनुपस्थिति की गारंटी देता है। क्योंकि उनके निर्माण के उसी क्षण से, यह मान लिया गया था कि अपवादों को बहुत कम ही फेंकना चाहिए ।

गतिशील के नुकसान (यानी नियमित) अपवाद:

फेंके गए अपवाद के मामले में, ओवरहेड औसतन 10,000-100,000 सीपीयू चक्रों पर होता है, और सबसे खराब स्थिति में, यह मिलीसेकंड के क्रम तक पहुंच सकता है
बाइनरी फ़ाइल का आकार 15-38% बढ़ा
C प्रोग्रामिंग इंटरफ़ेस के साथ असंगति
noexcept को छोड़कर सभी फंक्शन्स में noexcept अपवाद थ्रो सपोर्ट। एक अपवाद कार्यक्रम में लगभग कहीं भी फेंका जा सकता है, यहां तक कि जहां फ़ंक्शन लेखक को इसकी उम्मीद नहीं है

इन कमियों के कारण, अपवादों का दायरा काफी सीमित है। जब अपवाद लागू नहीं हो सकते:

जहां नियतत्ववाद महत्वपूर्ण है, अर्थात् जहां यह अस्वीकार्य है कि कोड "कभी-कभी" 10, 100, 1000 गुना सामान्य से अधिक काम करता है
जब वे एबीआई में समर्थित नहीं होते हैं, उदाहरण के लिए, माइक्रोकंट्रोलर में
जब कोड का एक बड़ा हिस्सा C में लिखा जाता है
विरासत कोड ( Google शैली गाइड , Qt ) के एक बड़े भार वाली कंपनियों में। यदि कोड में कम से कम एक गैर-अपवाद-सुरक्षित फ़ंक्शन है, तो मीनिंग ऑफ लॉ के अनुसार, इसके अलावा या बाद में इसके माध्यम से एक अपवाद फेंक दिया जाएगा और एक बग बनाएं
प्रोग्रामर को काम पर रखने वाली कंपनियों में जिन्हें अपवाद सुरक्षा के बारे में कोई जानकारी नहीं है

सर्वेक्षणों के अनुसार, 52% (!) डेवलपर्स के कार्यस्थलों में, अपवाद कॉर्पोरेट नियमों द्वारा निषिद्ध हैं।

लेकिन अपवाद सी ++ का एक अभिन्न हिस्सा हैं! -fno-exceptions ध्वज को शामिल करके, डेवलपर्स मानक पुस्तकालय के एक महत्वपूर्ण हिस्से का उपयोग करने की क्षमता खो देते हैं। यह आगे कंपनियों को अपने स्वयं के "मानक पुस्तकालयों" को लगाने के लिए उकसाता है और हां, अपने स्वयं के स्ट्रिंग क्लास का आविष्कार करता है।

लेकिन यह अंत नहीं है। निर्माण में किसी ऑब्जेक्ट के निर्माण को रद्द करने और त्रुटि को फेंकने के लिए अपवाद एकमात्र मानक तरीका है। जब उन्हें बंद कर दिया जाता है, तो दो-चरण के प्रारंभ के रूप में एक घृणा प्रकट होती है। ऑपरेटर भी त्रुटि कोड का उपयोग नहीं कर सकते हैं, इसलिए उन्हें assign कार्यों के साथ बदल दिया जाता है।

प्रस्ताव: भविष्य के अपवाद

नया अपवाद हस्तांतरण तंत्र

P709 में हर्ब सटर ने एक नए अपवाद हस्तांतरण तंत्र का वर्णन किया। सिद्धांत रूप में, फ़ंक्शन std::expected , हालांकि, bool प्रकार के एक अलग भेदभाव के बजाय, जो संरेखण के साथ मिलकर स्टैक पर 8 बाइट्स तक कब्जा कर लेगा, इस बिट जानकारी को कुछ तेज़ तरीके से प्रेषित किया जाता है, उदाहरण के लिए, कैरी फ्लैग।

फ़ंक्शंस जो सीएफ को नहीं छूते हैं (उनमें से अधिकांश) को स्थिर अपवाद का उपयोग करने का अवसर मिलेगा - सामान्य रिटर्न के मामले में और अपवाद फेंकने के मामले में! जिन कार्यों को सहेजने और पुनर्स्थापित करने के लिए मजबूर किया जाता है, उन्हें न्यूनतम ओवरहेड प्राप्त होगा, और यह अभी भी std::expected और किसी भी त्रुटि कोड से अधिक तेज होगा।

स्थैतिक अपवाद इस तरह दिखते हैं:

 int safe_divide(int i, int j) throws(arithmetic_errc) { if (j == 0) throw arithmetic_errc::divide_by_zero; if (i == INT_MIN && j == -1) throw arithmetic_errc::integer_divide_overflows; return i / j; } double foo(double i, double j, double k) throws(arithmetic_errc) { return i + safe_divide(j, k); } double bar(int i, double j, double k) { try { cout << foo(i, j, k); } catch (erithmetic_errc e) { cout << e; } }

वैकल्पिक संस्करण में, try i + safe_divide(j, k) फ़ंक्शन कॉल के रूप में उसी कीवर्ड में try कीवर्ड को उपकृत करने का प्रस्ताव है: try i + safe_divide(j, k) । इससे कोड में throws फ़ंक्शंस का उपयोग करने के मामलों की संख्या कम हो जाएगी जो अपवादों के लिए लगभग शून्य नहीं है। किसी भी मामले में, गतिशील अपवादों के विपरीत, आईडीई अपवादों को फेंकने वाले अभिव्यक्तियों को किसी तरह उजागर करने में सक्षम होगा।

यह तथ्य कि फेंके गए अपवाद को अलग से संग्रहीत नहीं किया जाता है, लेकिन सीधे लौटाए गए मान के स्थान पर रखा जाता है, अपवाद के प्रकार पर प्रतिबंध लगाता है। सबसे पहले, यह तुच्छ रूप से स्थानांतरित होना चाहिए। दूसरे, इसका आकार बहुत बड़ा नहीं होना चाहिए (लेकिन यह std::unique_ptr ) जैसा कुछ हो सकता है, अन्यथा सभी फ़ंक्शन स्टैक पर अधिक स्थान आरक्षित करेंगे।

status_code

Niall डगलस द्वारा विकसित <system_error2> पुस्तकालय में status_code<T> - "नया, बेहतर" error_code । error_code से मुख्य अंतर:

status_code - एक टेम्प्लेट प्रकार जो लगभग किसी भी बोधगम्य त्रुटि कोड को संग्रहीत करने के लिए इस्तेमाल किया जा सकता है (साथ में status_code_category लिए एक पॉइंटर के साथ), स्थिर अपवाद का उपयोग किए बिना।
T को त्रिविम रूप से स्थानांतरित और प्रतिलिपि योग्य होना चाहिए (बाद वाला, आईएमएचओ, अनिवार्य नहीं होना चाहिए)। जब कॉपी और डिलीट किया जाता है, तो वर्चुअल फ़ंक्शन को status_code_category से बुलाया जाता है
status_code न केवल त्रुटि डेटा संग्रहीत कर सकता है, बल्कि एक सफलतापूर्वक पूर्ण किए गए ऑपरेशन के बारे में अतिरिक्त जानकारी भी
"वर्चुअल" फ़ंक्शन code.message() std::string नहीं string_ref है, लेकिन string_ref एक अधिक भारी प्रकार का स्ट्रिंग है, जो एक वर्चुअल "संभवतः मालिक" std::string_view । वहां आप string_view या string , या std::shared_ptr<string> string_view std::shared_ptr<string> , या किसी स्ट्रिंग के मालिक का कोई अन्य पागल तरीका भर सकते हैं। Niall का दावा है कि #include <string> हेडर बना देगा <system_error2> अस्वीकार्य रूप से "भारी"

अगला, errored_status_code<T> दर्ज किया गया है - निम्न निर्माणकर्ता के साथ status_code<T> पर एक आवरण:

 errored_status_code(status_code<T>&& code) [[expects: code.failure() == true]] : code_(std::move(code)) {}

त्रुटि

डिफ़ॉल्ट अपवाद प्रकार (बिना प्रकार के throws ), साथ ही मूल प्रकार के अपवाद जिनमें अन्य सभी को डाला जाता है (जैसे std::exception ), error । इसे कुछ इस तरह परिभाषित किया गया है:

 using error = errored_status_code<intptr_t>;

यही है, error एक ऐसी "त्रुटि" status_code , जिसमें मान ( value ) 1 पॉइंटर में रखा गया है। चूंकि status_code_category तंत्र सही विलोपन, गति और प्रतिलिपि बनाना सुनिश्चित करता है, सैद्धांतिक रूप से, किसी भी डेटा संरचना को error में बचाया जा सकता है। व्यवहार में, यह निम्नलिखित विकल्पों में से एक होगा:

पूर्णांक (int)
std::exception_handle , अर्थात् एक फेंका हुआ गतिशील अपवाद का सूचक
status_code_ptr , अर्थात unique_ptr एक मनमाना status_code<T> ।

समस्या यह है कि स्थिति 3 को status_code<T> error वापस लाने का अवसर देने की योजना नहीं है। केवल एक चीज जो आप कर सकते हैं message() पैक्ड status_code<T> message() मिल सकता है। वापस error में लिपटे मूल्य प्राप्त करने में सक्षम होने के लिए, इसे एक गतिशील अपवाद (!) के रूप में फेंक दें, फिर इसे error पकड़ें और लपेटें। सामान्य तौर पर, Niall का मानना है कि केवल त्रुटि कोड और स्ट्रिंग संदेश error में संग्रहीत किए जाने चाहिए, जो किसी भी कार्यक्रम के लिए पर्याप्त है।

विभिन्न प्रकार की त्रुटियों के बीच अंतर करने के लिए, "वर्चुअल" तुलना ऑपरेटर का उपयोग करना प्रस्तावित है:

 try { open_file(name); } catch (std::error e) { if (e == filesystem_error::already_exists) { return; } else { throw my_exception("Unknown filesystem error, unable to continue"); } }

अपवाद के प्रकार का चयन करने के लिए कई कैच ब्लॉक या dynamic_cast का उपयोग करना विफल होगा!

गतिशील अपवादों के साथ सहभागिता

एक समारोह में निम्नलिखित विशिष्टताओं में से एक हो सकता है:

noexcept : कोई अपवाद नहीं फेंकता है
throws(E) : केवल स्थिर अपवाद फेंकता है
(कुछ नहीं): केवल गतिशील अपवाद फेंकता है

noexcept का तात्पर्य noexcept यदि एक गतिशील अपवाद को "स्थिर" फ़ंक्शन से फेंक दिया जाता है, तो यह error में लिपटा है। यदि एक स्थिर अपवाद को "गतिशील" फ़ंक्शन से फेंक दिया जाता है, तो यह एक status_error अपवाद में लपेटा जाता है। एक उदाहरण:

 void foo() throws(arithmetic_errc) { throw erithmetic_errc::divide_by_zero; } void bar() throws { //  arithmetic_errc   intptr_t //     error foo(); } void baz() { // error    status_error bar(); } void qux() throws { // error    status_error baz(); }

C में अपवाद !?

यह प्रस्ताव भविष्य के सी मानकों में से एक को शामिल करने के लिए प्रदान करता है, और ये अपवाद C ++ स्टैटिक के साथ ABI- संगत होंगे। std::expected<T, U> समान संरचना std::expected<T, U> , उपयोगकर्ता को स्वतंत्र रूप से घोषित करना होगा, हालांकि हॉलैंड्स से अतिरेक को हटाया जा सकता है। सिंटैक्स में (सादगी के लिए, हम इसे मान लेंगे) कीवर्ड विफल होते हैं, असफल होते हैं, पकड़ते हैं।

 int invert(int x) fails(float) { if (x != 0) return 1 / x; else return failure(2.0f); } struct expected_int_float { union { int value; float error; }; _Bool failed; }; void caller() { expected_int_float result = catch(invert(5)); if (result.failed) { print_error(result.error); return; } print_success(result.value); }

साथ ही, C ++ में, C से fails फ़ंक्शंस को कॉल करना भी संभव होगा, उन्हें extern C ब्लॉक में घोषित किया जाएगा। इस प्रकार, C ++ में अपवादों के साथ काम करने के लिए कीवर्ड की एक पूरी आकाशगंगा होगी:

throw() - सी ++ 20 में हटा दिया गया
noexcept - फ़ंक्शन विनिर्देशक, फ़ंक्शन गतिशील अपवादों को नहीं फेंकता है
noexcept(expression) - फ़ंक्शन विनिर्देशक, फ़ंक्शन प्रदान किए गए गतिशील अपवादों को नहीं फेंकता है
noexcept(expression) - क्या कोई अभिव्यक्ति गतिशील अपवादों को noexcept(expression) है?
throws(E) - फ़ंक्शन निर्दिष्ट करता है, फ़ंक्शन स्थिर अपवादों को फेंकता है
throws = throws(std::error)
fails(E) - सी से आयातित एक समारोह स्थैतिक अपवाद फेंकता है

इसलिए, सी ++ में वे त्रुटि से निपटने के लिए नए उपकरणों की एक गाड़ी (या बल्कि, वितरित) लाए। अगला, एक तार्किक सवाल उठता है:

कब क्या उपयोग करना है?

सामान्य दिशा

त्रुटियों को कई स्तरों में विभाजित किया गया है:

प्रोग्रामर त्रुटियों। अनुबंधों का उपयोग करके संसाधित। वे विफल-फास्ट की अवधारणा के अनुसार लॉग के संग्रह और कार्यक्रम की समाप्ति का नेतृत्व करते हैं। उदाहरण: अशक्त सूचक (जब यह अमान्य है); शून्य से विभाजन; मेमोरी एलोकेशन एरर को प्रोग्रामर ने नहीं देखा।
प्रोग्रामर द्वारा प्रदान की गई घातक त्रुटियां। एक फ़ंक्शन से एक सामान्य रिटर्न की तुलना में एक लाख गुना कम बार फेंको, जो गतिशील अपवादों के उपयोग को उनके लिए उचित बनाता है। आमतौर पर, ऐसे मामलों में, आपको ऑपरेशन करते समय प्रोग्राम के पूरे सबसिस्टम को पुनः आरंभ करने या त्रुटि देने की आवश्यकता होती है। उदाहरण: डेटाबेस से अचानक खोया हुआ संबंध; प्रोग्रामर द्वारा प्रदान की गई मेमोरी एलोकेशन एरर।
पुनर्प्राप्त करने योग्य त्रुटियां जब फ़ंक्शन ने अपने कार्य को पूरा करने से रोका, लेकिन कॉलिंग फ़ंक्शन को पता चल सकता है कि इसके साथ क्या करना है। स्थिर अपवादों द्वारा नियंत्रित। उदाहरण: फ़ाइल सिस्टम के साथ काम करना; अन्य इनपुट / आउटपुट (IO) त्रुटियां; गलत उपयोगकर्ता डेटा vector::at() ।
एक अप्रत्याशित परिणाम के साथ, फ़ंक्शन ने सफलतापूर्वक अपना काम पूरा किया। std::optional , std::expected , std::variant । उदाहरण: stoi() ; vector::find() ; map::insert ।

मानक पुस्तकालय में, "अपवादों के बिना" कानूनी रूप से संकलन करने के लिए गतिशील अपवादों के उपयोग को पूरी तरह से छोड़ना सबसे विश्वसनीय है।

errno

C और C ++ त्रुटि कोड के साथ जल्दी और आसानी से काम करने के लिए errno का उपयोग करने वाले कार्यों को क्रमशः fails(int) और throws(std::errc) साथ प्रतिस्थापित किया जाना चाहिए। कुछ समय के लिए, मानक पुस्तकालय के कार्यों के पुराने और नए संस्करण सह-अस्तित्व में आएंगे, फिर पुराने को अप्रचलित घोषित किया जाएगा।

स्मृति से बाहर

मेमोरी आवंटन त्रुटियों को new_handler ग्लोबल हुक द्वारा नियंत्रित किया जाता है, जो कर सकते हैं:

स्मृति की कमी को दूर करें और निष्पादन जारी रखें
एक अपवाद फेंक दें
क्रैश प्रोग्राम

अब std::bad_alloc डिफ़ॉल्ट रूप std::bad_alloc फेंक दिया जाता है। यह डिफ़ॉल्ट रूप से std::terminate() को कॉल करने का सुझाव दिया गया है। यदि आपको पुराने व्यवहार की आवश्यकता है, तो हैंडलर को main() की शुरुआत में आपकी ज़रूरत के साथ बदलें।

मानक लाइब्रेरी के सभी मौजूदा कार्य noexcept हो noexcept और जब std::bad_alloc होगा तो प्रोग्राम को क्रैश कर देगा। उसी समय, vector::try_push_back जैसे नए एपीआई vector::try_push_back जोड़े जाएंगे, जो मेमोरी आवंटन त्रुटियों की अनुमति देते हैं।

`logic_error`

अपवाद std::logic_error , std::logic_error , std::domain_error , std::invalid_argument std::length_error , std::out_of_range , std::future_error किसी फ़ंक्शन पूर्व शर्त के उल्लंघन की रिपोर्ट करते हैं। नए त्रुटि मॉडल के बजाय अनुबंध का उपयोग करना चाहिए। सूचीबद्ध प्रकार के अपवादों को पदावनत नहीं किया जाएगा, लेकिन मानक पुस्तकालय में उनके उपयोग के लगभग सभी मामलों को [[expects: …]] द्वारा प्रतिस्थापित किया जाएगा।

वर्तमान प्रस्ताव स्थिति

प्रस्ताव अब एक मसौदा राज्य में है। यह पहले से ही काफी बदल गया है, और अभी भी बहुत कुछ बदल सकता है। कुछ घटनाक्रम प्रकाशित होने का प्रबंधन नहीं करते हैं, इसलिए प्रस्तावित API <system_error2> पूरी तरह से प्रासंगिक नहीं है।

प्रस्ताव 3 दस्तावेजों में वर्णित है:

P709 - सटर के हथियारों के कोट से मूल दस्तावेज
P1095 - नियाल डगलस विज़न में निर्धारित अपवाद, कुछ क्षणों में परिवर्तन , सी भाषा की संगतता
P1028 - std::error के परीक्षण कार्यान्वयन से एपीआई

वर्तमान में कोई संकलक नहीं है जो स्थैतिक अपवादों का समर्थन करता है। तदनुसार, अभी तक उनके बेंचमार्क बनाना संभव नहीं है।

C++23. , , , C++26, , , .

निष्कर्ष

, , . , . .

, ^^

भविष्य के "C ++" में नियतात्मक अपवाद और त्रुटि से निपटने