CreateFile जैसे कुछ विंडोज फ़ंक्शन विशालGetLastError नामक त्रुटि कोडों की विविधता वापस कर सकते हैं, और प्रत्येक संभावित त्रुटि कोड की जांच करने के लिए अव्यवहारिक है - अक्सर पर्याप्त दस्तावेज नहीं होते हैं, और नए त्रुटि कोड अक्सर जोड़े जाते हैं।मुझे कौन सी त्रुटियों को संभालना चाहिए? कौन सा "घातक" हैं?
उनमें से कुछ (जैसे एक्सेस उल्लंघन या अमान्य पैरामीटर) प्रोग्रामर त्रुटि के कारण हैं और प्रोग्राम निष्पादन की निरंतरता की अनुमति नहीं देनी चाहिए। हालांकि, अन्य अन्य कारकों के कारण हैं, जैसे खराब फ़ाइल अनुमतियां, उल्लंघन साझा करना, खराब फ़ाइल नाम इत्यादि, जिसे डेवलपर के पास बहुत कम या कोई नियंत्रण नहीं है।
मैं अपने कार्यक्रम को क्रैश करने के लिए "गंभीर त्रुटियों" (जैसे उल्लंघन उल्लंघन) की अनुमति देते हुए सभी "गैर-महत्वपूर्ण" त्रुटियों (जैसे खराब फ़ाइल नाम) को संभालना चाहता हूं।
आदर्श रूप में, मैं कह रहा की जाएगी:
// ... an error occurred. Is it a programmer error?
if (IsErrorCritical(GetLastError()))
{
// Yes; raise an exception, crashing the program.
RaiseException(GetLastError(), 0, 0, NULL);
}
मैं कैसे तय करते हैं जो त्रुटि कोड को दबाने के लिए सुरक्षित हैं (उदाहरण के लिए, जब एक डिस्क पर फ़ाइलों की गणना), जब मैं संभवतः प्रत्येक और हर परिणाम अनुमान नहीं लगा सकते ?
मैं तर्क दूंगा कि वास्तव में असाधारण परिस्थितियों (प्रवेश उल्लंघन, आदि) को छोड़कर एक कार्यक्रम कभी क्रैश नहीं होना चाहिए। फ़ाइल बनाने में विफल होने की उम्मीद विफलता होनी चाहिए और एक सुंदर तरीके से संभाला जाना चाहिए। इसके अलावा, जैसे ही कुछ नया त्रुटि कोड जोड़ा जाता है, आपका IsErrorCritical() फ़ंक्शन पुराना हो जाएगा। – Luke
ठीक है, लेकिन मुझे कैसे पता चलेगा कि कुछ "वास्तव में असाधारण" है या नहीं? यही सवाल है .. – Mehrdad
जब मैं असाधारण कहता हूं तो मेरा मतलब बिल्कुल है। उल्लंघन का उल्लंघन और स्मृति से बाहर चलना दो बड़े हैं; अन्य हो सकते हैं, लेकिन आपको विचार मिलता है। यदि CreateFile() विफल होने से आपके प्रोग्राम को क्रैश हो जाता है तो आप इसे गलत IMHO कर रहे हैं। – Luke