सी में हर छोटी सी त्रुटि के लिए एक की जाँच करनी चाहिए?

Question

एक अच्छे प्रोग्रामर के रूप में एक मजबूत कोड लिखना चाहिए जो उनके प्रोग्राम के हर एक परिणाम को संभाल लेगा। हालाँकि, C लाइब्रेरी से लगभग सभी फ़ंक्शंस 0 या -1 या NULL वापस होंगे जब कोई त्रुटि होगी।

यह कभी-कभी स्पष्ट होता है कि त्रुटि जाँच आवश्यक है, उदाहरण के लिए जब आप किसी फ़ाइल को खोलने का प्रयास करते हैं। लेकिन मैं अक्सर कार्यों में त्रुटि की जाँच को अनदेखा कर देता हूँ जैसे कि printfया यहाँ तक कि mallocक्योंकि मुझे आवश्यक नहीं लगता है।

if(fprintf(stderr, "%s", errMsg) < 0){
    perror("An error occurred while displaying the previous error.");
    exit(1);
}

क्या कुछ त्रुटियों को अनदेखा करना एक अच्छा अभ्यास है, या सभी त्रुटियों को संभालने का एक बेहतर तरीका है?

Comments

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

— rwong

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

— एरिक इद्ट

समस्या ज्यादातर एक कार्यप्रणाली है: आप आम तौर पर त्रुटि जाँच नहीं लिखते हैं जब आप अभी भी यह पता लगा रहे हैं कि आप क्या लागू करने वाले हैं और आप अभी त्रुटि जाँच नहीं करना चाहते हैं क्योंकि आप "खुशहाल मार्ग" प्राप्त करना चाहते हैं। सबसे पहले। लेकिन आप अभी भी मॉलोक और सह के लिए जाँच करने वाले हैं । त्रुटि जाँच चरण को छोड़ देने के बजाय, आपको अपनी कोडिंग गतिविधियों को प्राथमिकता देनी होगी और त्रुटि जाँच को अपनी TODO सूची में एक अंतर्निहित स्थायी रीफ़ैक्टरिंग चरण होने देना चाहिए, जब भी आप अपने कोड से संतुष्ट हों। Greppable "/ * CHECK * /" टिप्पणियों को जोड़ने से मदद मिल सकती है।

— कोरडंप

मैं विश्वास नहीं कर सकता कि किसी का उल्लेख नहीं है errno! मामले में आप परिचित नहीं हैं, जबकि यह सच है कि "सी लाइब्रेरी से लगभग सभी फ़ंक्शन 0 या ,1 या NULLजब कोई त्रुटि होगी," वे वैश्विक errnoचर भी सेट करते हैं , जिसे आप उपयोग करके #include <errno.h>और फिर बस पढ़ सकते हैं का मूल्य errno। इसलिए, उदाहरण के लिए, यदि open(2) रिटर्न मिलता है -1, तो आप जांचना चाह सकते हैं कि क्या errno == EACCES, जो एक अनुमति त्रुटि ENOENTको इंगित करेगा , या , जो इंगित करेगा कि अनुरोधित फ़ाइल मौजूद नहीं है।

— वॉचर्जिन नोव

@ ErikEidt C समर्थन नहीं करता है try/ catch, हालांकि आप इसे जंप के साथ अनुकरण कर सकते हैं।

— मस्त

Answer 1

सामान्य तौर पर, कोड को जहां भी उपयुक्त हो असाधारण स्थितियों से निपटना चाहिए। हां, यह एक अस्पष्ट बयान है।

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

सी में, आपके पास वह लक्जरी नहीं है। त्रुटियों को संभालने के कुछ तरीके हैं, जिनमें से कुछ भाषा / पुस्तकालय की विशेषताएं हैं, जिनमें से कुछ कोडिंग प्रथाएं हैं।

क्या कुछ त्रुटियों को अनदेखा करना एक अच्छा अभ्यास है, या सभी त्रुटियों को संभालने का एक बेहतर तरीका है?

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

सभी को संभालने के तरीके हैं, या कम से कम अधिकांश, त्रुटियां:

1. त्रुटि से निपटने के लिए, आप गोटो के समान जंप का उपयोग कर सकते हैं । जबकि सॉफ्टवेयर पेशेवरों के बीच एक विवादास्पद मुद्दा है, विशेष रूप से एम्बेडेड और प्रदर्शन-महत्वपूर्ण कोड (जैसे लिनक्स कर्नेल) में उनके लिए वैध उपयोग हैं।

2. कैस्केडिंग ifs:

   if (!<something>) {
     printf("oh no 1!");
     return;
   }
   if (!<something else>) {
     printf("oh no 2!");
     return;
   }
   

3. पहली स्थिति का परीक्षण करें, उदाहरण के लिए फ़ाइल खोलना या बनाना, फिर बाद के संचालन को सफल मानें।

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

Comments

क्षमा करें, यहाँ लेने के लिए मामूली नाइट - "मानक आउटपुट पर लेखन विफल नहीं होगा। यदि यह विफल होता है, तो आप उपयोगकर्ता को कैसे बताएंगे, वैसे भी?" - मानक त्रुटि को लिखकर? इसमें कोई गारंटी नहीं है कि एक लिखने में विफलता का मतलब है कि दूसरे को लिखना असंभव है।

— डेमियन_इन_यूएनबेलिवर

@Damien_The_Unbeliever - विशेष रूप से चूंकि stdoutफ़ाइल को पुनर्निर्देशित किया जा सकता है, या सिस्टम के आधार पर भी मौजूद नहीं है। stdoutस्ट्रीम के लिए "राइट टू कंसोल" नहीं है, यह आमतौर पर ऐसा होता है, लेकिन यह होना जरूरी नहीं है।

— dralo

@ जेएबी आप एक संदेश भेजते हैं stdout... स्पष्ट :-)

— ट्रिपहाउंड

@JAB: यदि आप उचित थे, तो आप EX_IOERR से बाहर निकल सकते हैं।

— जॉन मार्शल

आप जो भी करते हैं, नहीं है बस के रूप में हालांकि कुछ भी नहीं हुआ है चल रहा है पर ले जाने के! यदि कमांड dump_database > backups/db_dump.txtकिसी भी बिंदु पर मानक आउटपुट में लिखने में विफल रहता है, तो मैं नहीं चाहूंगा कि यह सफलतापूर्वक चले और आगे निकले। (ऐसा नहीं है कि डेटाबेस को इस तरह से बैकअप दिया जाता है, लेकिन बिंदु अभी भी खड़ा है)

— बेन एस

Answer 2

हालाँकि, C लाइब्रेरी से लगभग सभी फ़ंक्शंस 0 या -1 या NULL वापस होंगे जब कोई त्रुटि होगी।

हां, लेकिन आप जानते हैं कि आपने किस फंक्शन को बुलाया है, है न?

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

आपको प्रत्येक फ़ंक्शन कॉल के लिए ऐसा करने की आवश्यकता नहीं है। लेकिन जब आप पहली बार त्रुटि संदेश देखते हैं "पिछली त्रुटि प्रदर्शित करते समय एक त्रुटि हुई," जब आपको वास्तव में आवश्यक जानकारी थी, तो आखिरी बार होगा जब आप कभी भी उस त्रुटि संदेश को देखेंगे, क्योंकि आप तुरंत बदलने जा रहे हैं। कुछ जानकारीपूर्ण के लिए त्रुटि संदेश जो समस्या का निवारण करने में आपकी सहायता करेगा।

Comments

इस जवाब ने मुझे मुस्कुरा दिया, क्योंकि यह सच है, लेकिन सवाल का जवाब नहीं देता।

— रबड़डुक

यह प्रश्न का उत्तर कैसे नहीं देता है?

— रॉबर्ट हार्वे

एक कारण मुझे लगता है कि सी (और अन्य भाषाओं) को बूलियन मिला 1 और 0 मिलाया गया वही कारण है कि कोई भी सभ्य फ़ंक्शन त्रुटि कोड देता है "0" बिना किसी त्रुटि के। लेकिन फिर तुम कहना होगा if (!myfunc()) {/*proceed*/}। 0 कोई त्रुटि नहीं थी, और गैर-शून्य कुछ थोड़े त्रुटि थी और प्रत्येक थोड़े त्रुटि का अपना गैर-शून्य कोड था। जिस तरह से मेरे एक दोस्त ने यह कहा था "केवल एक सत्य है, लेकिन कई झूठ हैं।" if()परीक्षण में "0" को "सत्य" होना चाहिए और गैर-शून्य कुछ भी "असत्य" होना चाहिए।

— रोबर्ट ब्रिस्टो-जॉनसन

नहीं, इसे अपने तरीके से करने पर, केवल एक संभव नकारात्मक त्रुटि कोड है। और कई संभव no_error कोड।

— रोबर्ट ब्रिस्टो-जॉनसन

@ robertbristow-johnson: इसके बाद इसे पढ़ें "कोई त्रुटि नहीं थी।" if(function()) { // do something }पढ़ता है "यदि फ़ंक्शन बिना किसी त्रुटि के निष्पादित होता है, तो कुछ करें।" या, और भी बेहतर, "यदि फ़ंक्शन सफलतापूर्वक निष्पादित होता है, तो कुछ करें।" गंभीरता से, जो लोग सम्मेलन को समझते हैं वे इससे भ्रमित नहीं होते हैं । falseजब कोई त्रुटि होती है, तो रिटर्निंग (या 0) त्रुटि कोड का उपयोग करने की अनुमति नहीं देता है। शून्य का अर्थ है C में असत्य क्योंकि गणित कैसे काम करता है। प्रोग्रामर्स

— रॉबर्ट हार्वे

Answer 3

TLDR; आपको त्रुटियों को लगभग कभी भी अनदेखा नहीं करना चाहिए।

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

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

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

हालाँकि C डेवलपर के रूप में कोड को बनाए रखना आसान बनाना भी आपका काम है। तो कभी-कभी आप स्पष्टता के लिए त्रुटियों को सुरक्षित रूप से अनदेखा कर सकते हैं यदि (और केवल अगर) तो वे आवेदन के समग्र व्यवहार के लिए कोई खतरा नहीं पैदा करते हैं। ।

यह ऐसा करने के रूप में एक ही समस्या है:

try
{
    run();
} catch (Exception) {
    // comments expected here!!!
}

यदि आप देखते हैं कि खाली कैच ब्लॉक के अंदर कोई अच्छी टिप्पणी नहीं है, तो यह निश्चित रूप से एक मुद्दा है। malloc()100% समय को सफलतापूर्वक निष्पादित करने के लिए एक कॉल सोचने का कोई कारण नहीं है ।

Comments

मैं मानता हूं कि स्थायित्व वास्तव में एक महत्वपूर्ण पहलू है और उस अनुच्छेद ने वास्तव में मेरे प्रश्न का उत्तर दिया है। विस्तृत उत्तर के लिए धन्यवाद।

— डेरेक 會 會 ere

मुझे लगता है कि कार्यक्रमों के गजिलियन्स जो कभी भी उनके मॉलोक कॉल की जांच करने के लिए परेशान नहीं करते हैं और फिर भी कभी भी दुर्घटना नहीं होती है आलसी होने का एक अच्छा कारण है जब एक डेस्कटॉप प्रोग्राम केवल कुछ एमबीएस मेमोरी का उपयोग करता है।

— whatsisname

@whatsisname: क्योंकि वे दुर्घटना नहीं करते हैं, इसका मतलब यह नहीं है कि वे चुपचाप डेटा भ्रष्ट नहीं कर रहे हैं। malloc()एक फ़ंक्शन है जिस पर आप निश्चित रूप से रिटर्न मानों की जांच करना चाहते हैं!

— टीएमएन

@TMN: यदि मॉलॉक कार्यक्रम को तुरंत विफल कर देता है और समाप्त कर देता है, तो वह सामान नहीं ले जाएगा। यह जोखिम के बारे में है और क्या उचित है, "लगभग कभी नहीं"।

— whatsisname

@ एलेक्स सी में अच्छे एरर हैंडलिंग की कमी नहीं है। यदि आप अपवाद चाहते हैं, तो आप उनका उपयोग कर सकते हैं। अपवादों का उपयोग नहीं करने वाली मानक लाइब्रेरी एक जानबूझकर पसंद है (अपवाद आपको स्वचालित मेमोरी प्रबंधन करने के लिए मजबूर करते हैं और अक्सर आप निम्न-स्तरीय कोड के लिए नहीं चाहते हैं)।

— मार्टिंक्यूनेव

Answer 4

प्रश्न वास्तव में भाषा विशिष्ट नहीं है, बल्कि उपयोगकर्ता विशिष्ट है। उपयोगकर्ता के दृष्टिकोण से प्रश्न के बारे में सोचें। उपयोगकर्ता कुछ करता है, जैसे कमांड लाइन पर प्रोग्राम का नाम टाइप करना और एंटर करना। उपयोगकर्ता क्या उम्मीद करता है? अगर कुछ गलत हुआ तो वे कैसे बता सकते हैं? यदि कोई त्रुटि होती है, तो क्या वे हस्तक्षेप करना बर्दाश्त कर सकते हैं?

कई तरह के कोड में, ऐसे चेक ओवरकिल होते हैं। हालांकि, उच्च विश्वसनीयता सुरक्षा महत्वपूर्ण कोड में, जैसे कि परमाणु रिएक्टरों के लिए, पैथोलॉजिकल एरर चेकिंग और नियोजित रिकवरी पथ नौकरी के दिन-प्रतिदिन की प्रकृति का हिस्सा हैं। यह पूछने के लिए लागत के लायक है कि "एक्स विफल हो जाता है तो क्या होता है? मैं एक सुरक्षित स्थिति में वापस कैसे आता हूं?" कम विश्वसनीय कोड में, जैसे कि वीडियो गेम के लिए, आप कम त्रुटि जांच से दूर हो सकते हैं।

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

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

Answer 5

• विभिन्न सुरक्षा आवश्यकताएं शुद्धता के विभिन्न स्तरों की मांग करती हैं। विमानन या ऑटोमोबाइल नियंत्रण सॉफ्टवेयर में सभी वापसी मूल्यों की जाँच की जाएगी, सीएफ। MISRA.FUNC.UNUSEDRET । अवधारणा के एक त्वरित प्रमाण में जो आपकी मशीन को कभी नहीं छोड़ता है, शायद नहीं।
• कोडिंग में समय लगता है। गैर-सुरक्षित-महत्वपूर्ण सॉफ़्टवेयर में बहुत अधिक अप्रासंगिक जाँचें कहीं और बेहतर ढंग से खर्च करने का प्रयास है। लेकिन गुणवत्ता और लागत के बीच मधुर स्थान कहां है? यह डीबगिंग टूल और सॉफ़्टवेयर जटिलता पर निर्भर करता है।
• त्रुटि हैंडलिंग नियंत्रण प्रवाह को अस्पष्ट कर सकती है और नई त्रुटियों को पेश कर सकती है। मैं रिचर्ड "नेटवर्क" स्टीवंस के रैपर कार्यों को बहुत पसंद करता हूं जो कम से कम त्रुटियों की रिपोर्ट करते हैं।
• त्रुटि से निपटने, शायद ही कभी, एक प्रदर्शन मुद्दा हो सकता है। लेकिन ज्यादातर सी लाइब्रेरी कॉल में इतना समय लगेगा कि रिटर्न वैल्यू चेक करने की लागत बेहद कम है।

Answer 6

थोड़ा सार प्रश्न पर ले जाता है। और यह सी भाषा के लिए जरूरी नहीं है।

बड़े कार्यक्रमों के लिए आपके पास एक अमूर्त परत होगी; शायद इंजन का एक हिस्सा, एक पुस्तकालय या एक ढांचे के भीतर। यही कारण है कि परत मौसम के बारे में परवाह नहीं करेंगे आप एक वैध डेटा प्राप्त या उत्पादन कुछ डिफ़ॉल्ट मान होगा: 0, -1, nullआदि

फिर एक लेयर होती है जो एब्स्ट्रैक्ट लेयर के लिए आपका इंटरफेस होगा, जो कि बहुत सारी एरर हैंडलिंग और शायद अन्य चीजें जैसे डिपेंडेंसी इंजैक्शन, ईवेंट सुनने आदि के बारे में बताएगा।

और बाद में आपके पास अपनी ठोस कार्यान्वयन परत होगी जहां आप वास्तव में नियम निर्धारित करते हैं और आउटपुट को संभालते हैं।

इसलिए मेरा यह मानना ​​है कि कभी-कभी कोड के एक हिस्से से त्रुटि से पूरी तरह से बाहर करना बेहतर होता है क्योंकि यह हिस्सा बस उस काम को नहीं करता है। और फिर कुछ प्रोसेसर हैं जो आउटपुट का मूल्यांकन करेंगे और एक त्रुटि को इंगित करेंगे।

यह ज्यादातर उन जिम्मेदारियों को अलग करने के लिए किया जाता है जो कोड पठनीयता और बेहतर मापनीयता की ओर जाता है।

Answer 7

सामान्य तौर पर, जब तक आपके पास उस त्रुटि स्थिति की जांच नहीं करने का एक अच्छा कारण है, तब तक आपको होना चाहिए। एक ही अच्छा कारण है कि मैं एक त्रुटि स्थिति के लिए जाँच नहीं करने के लिए सोच सकता हूँ जब आप संभवतः कुछ सार्थक नहीं कर सकते अगर यह विफल रहता है। हालांकि मिलने के लिए यह एक बहुत कठिन पट्टी है, क्योंकि हमेशा एक व्यवहार्य विकल्प होता है: इनायत से बाहर निकलें।

Comments

मैं आमतौर पर आपसे असहमत होता हूं क्योंकि त्रुटियां ऐसी परिस्थितियां हैं जिनका आपने हिसाब नहीं दिया है। यह जानना मुश्किल है कि त्रुटि कैसे प्रकट हो सकती है यदि आप नहीं जानते हैं कि त्रुटि किस स्थिति में है। और इस प्रकार डेटा के वास्तविक प्रसंस्करण से पहले त्रुटि से निपटने।

— क्रिएटिव मैजिक

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

— चतुर नेओलिज़्म