प्रोग्राम को जिंदा रखने के लिए अनदेखा (गंभीर) त्रुटियां?

Question

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

• क्या यह "प्रतिमान" का नाम है? मेरा मतलब है
• उपरोक्त करने के लिए कितना बुरा है?
• क्या वहां उपयोग करने के लिए प्रोग्राम हैं जो अभी भी पालन करते हैं: "अरे, यह एक घातक, अप्रत्याशित त्रुटि है - लेकिन आप जानते हैं क्या? मुझे परवाह नहीं है!"?

Answer 1

नामकरण पर, आप कह सकते हैं कि भाषा "सुअर-सिरदर्द" प्रदर्शित करती है।

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

आप सभी आधुनिक भाषाओं में सभी अपवाद हैंडलर पकड़ने के साथ समान बाहवीर लागू कर सकते हैं।

Answer 2

मुझे एक नाम के बारे में पता नहीं है।

यह कितना बुरा है? मुझे नहीं पता; आप इसके लिए क्या उपयोग कर रहे हैं? आमतौर पर, एक चुप त्रुटि से दुर्घटनाग्रस्त होना बेहतर होता है। क्रैश स्पष्ट होते हैं, और आमतौर पर सही किया जा सकता है, लेकिन चुप त्रुटियों को ध्यान में रखा जा सकता है, और इससे कोई फर्क नहीं पड़ता कि उन्हें सही करना कितना आसान है।

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

Answer 3

आपके प्रोग्राम को आगे बढ़ने के लिए, आपको एक बुनियादी स्थिति रखना होगा जो आपको पता है, और फिर प्रत्येक अनुरोध को स्वतंत्र रूप से संसाधित किया जाता है। उदाहरण के लिए:

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

सबसे बड़ी बात यह है कि तुम क्या कर रहे हैं तो यह है कि आपके आवेदन कुछ अलघुकरणीय कोर कि बग-मुक्त है होना आवश्यक है की सावधान रहना होगा, और किसी भी अनियोजित अपवाद (नहीं एक आसान काम) को संभाल लेंगे। उल्लेख नहीं है कि अप्रत्याशित अपवादों को निगलने से समस्या निवारण/डिबगिंग दुखी हो सकती है, irreducible कोर विफल नहीं हो सकता है, या अन्यथा पूरा एप्लिकेशन विफल हो जाएगा।

Answer 4

मैं त्रुटियों को संभालने की 'सैन्य टोपोलॉजी' विधि के साथ गया।

त्रुटियों को गंभीरता से वर्गीकृत किया जाना चाहिए, फिर या तो संकल्प के लिए बेहतर से निपटने या पारित किया जाना चाहिए।

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

यदि परेड ग्राउंड में दुश्मन सैनिकों के लैंडिंग का एक प्लूटून है तो शायद वह कुछ ऐसा है जो उसे अपने वरिष्ठों को बताना चाहिए।

जब आप अमीर और मशहूर हों तो कृपया मुझे अपनी पुस्तक के 'स्नर्क' अनुभाग में क्रेडिट करें।

Answer 5

आप मानते हैं कि यह निर्धारित करना संभव है कि प्रकार एक्स की सभी त्रुटियां शो-स्टॉपर्स हैं और टाइप वाई की सभी त्रुटियां नहीं हैं। मुझे लगता है कि यह सतह पर ठीक लगता है लेकिन शैतान विवरण में है। प्रैक्टिस में, मुझे नहीं लगता कि आप एक त्रुटि के बारे में सोच सकते हैं जो हमेशा सौम्य होता है।

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

जो मैं पढ़ रहा हूं वह यह है कि आप एक निश्चित कल्पना, एक बहुमुखी संकलक चाहते हैं जो वाक्यविन्यास को विभिन्न तरीकों से लिखने की अनुमति देता है, और गतिशील टाइपिंग सिस्टम। यह बहुत अच्छा है और मैं आपको शुभकामनाएं देता हूं। लेकिन कोडर की जानबूझकर व्याख्या करने के साथ इसे भ्रमित न करें और सोचें कि आप हानिकारक से ठीक त्रुटि बता सकते हैं।

Answer 6

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

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

Answer 7

एरलांग दृष्टिकोण काफी संतुलित लगता है। यदि कोई प्रक्रिया विफल हो जाती है, तो यह (आदर्श) दूसरों को प्रभावित नहीं करेगा।