C # में सुरक्षित रूप से अपवाद

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

खुद की क्लास । अपवाद के आधार पर आपकी अपनी श्रेणी के आधार पर Exception , और सीधे Exception के आधार पर नहीं, क्योंकि यह आपके अपने हैंडलर को परिभाषित करना और आपके कोड और .NET फ्रेमवर्क के कोड द्वारा फेंके गए अपवादों की ट्रैकिंग और हैंडलिंग को अलग करना संभव बनाता है।

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

लॉग करने के लिए संदेश । जब भी हैंडलर Exception.ToString(); कॉल करके एक Exception को पकड़ता है, तो एक संदेश दर्ज करें Exception.ToString(); अपवादों को डीबग करते समय यह ट्रैकिंग को आसान बना देगा।

सटीक वर्ग । अपवादों को पकड़ने के लिए कम से कम सामान्य वर्ग का उपयोग करें, अन्यथा यह हार्ड-टू-डिटेक्ट त्रुटियों का कारण बन सकता है। निम्नलिखित कोड पर विचार करें:

 public class SimpleClass { public static string DoSomething() { try { return SimpleLibrary.ReportStatus(); } catch (Exception) { return "Failure 1"; } } } public class SimpleLibrary { public static string ReportStatus() { return String.Format("Success {0}.", 0); } } 

यदि हम मानते हैं कि SimpleClass और SimpleClass SimpleLibrary का कोड अलग-अलग असेंबली में है, तो यदि दोनों असेंबली को सही तरीके से इंस्टॉल किया गया है, तो कोड को सही तरीके से निष्पादित किया जाता है, संदेश "सक्सेस 0" को प्रदर्शित करता है, और अगर SimpleLibrary क्लास के साथ असेंबली स्थापित नहीं है, तो कोड गलत तरीके से निष्पादित होता है। संदेश "विफलता 1" प्रदर्शित करना, इस तथ्य के बावजूद कि ReportStatus फ़ंक्शन को निष्पादित करते समय कोई त्रुटि नहीं हुई। अत्यधिक सामान्य अपवाद हैंडलिंग के कारण समस्या स्पष्ट नहीं है। लाइन को फ़ॉर्मेट करने वाला कोड ArgumentNullException और FormatException फेंकता FormatException , इसलिए ये अपवाद हैं जिन्हें कैच ब्लॉक में पकड़ा जाना चाहिए, फिर त्रुटि का कारण स्पष्ट हो जाएगा - यह FileNotFoundException अपवाद है क्योंकि विधानसभा के SimpleLibrary वर्ग के अभाव या गलत स्थापना के कारण।

पर्याप्त प्रसंस्करण । हमेशा अपवादों को सूचनात्मक रूप से संभालें। कोड देखें

 try { DoSomething(); } catch (SomeException) { // TODO: ... } 

समस्याओं को छुपाता है, डिबगिंग या निष्पादन के दौरान उनका पता लगाने से रोकता है।

finally ब्लॉक में समाशोधन । finally ब्लॉक में अस्थायी वस्तुओं को हटा दें। एक अस्थायी फ़ाइल लिखने के संचालन पर विचार करें।

 void WorkWithFile(string filename) { try { using (StreamWriter sw = new StreamWriter(filename)) { // TODO: Do something with temporary file } File.Delete(filename); } catch (Exception) { File.Delete(filename); throw; } } 

जैसा कि आप देख सकते हैं, फ़ाइल को हटाने वाला कोड डुप्लिकेट है। पुनरावृत्ति से बचने के लिए, आपको finally ब्लॉक से अस्थायी फ़ाइल को हटाने की आवश्यकता है।

 void WorkWithFile(string filename) { try { using (StreamWriter sw = new StreamWriter(filename)) { // TODO: Do something with temporary file } } finally { File.Delete(filename); } } 

कथन का उपयोग करना using कथन का using करें। यह Dispose पद्धति के लिए एक कॉल की गारंटी देता है, भले ही ऑब्जेक्ट में विधियों को कॉल करते समय कोई अपवाद हो।

 using (Font f = new Font("Times New Roman", 12.0f)) { byte charset = f.GdiCharSet; } 

using कथन का using करना एक try/finally ब्लॉक के बराबर है, लेकिन अधिक कॉम्पैक्ट और संक्षिप्त है।

 Font f = new Font("Times New Roman", 12.0f); try { byte charset = f.GdiCharSet; } finally { if (f != null) ((IDisposable)f).Dispose(); } 

समारोह का परिणाम है । फ़ंक्शन के परिणाम को वापस करने के लिए अपवादों का उपयोग न करें और त्रुटियों को संभालने के लिए विशेष रिटर्न कोड का उपयोग न करें। प्रत्येक को - उसका अपना। फ़ंक्शन का परिणाम लौटाया जाना चाहिए, और जो त्रुटियां नहीं छोड़ी जा सकती हैं उन्हें अपवादों के साथ नियंत्रित किया जाना चाहिए।

संसाधन की कमी । यदि कोई संसाधन नहीं है, तो null लौटें। .NET API के लिए आम तौर पर स्वीकार किए गए कन्वेंशन के अनुसार, फ़ंक्शन को संसाधन की अनुपस्थिति में अपवाद नहीं फेंकना चाहिए, उन्हें null होना चाहिए। यदि संसाधन संकलन में निर्दिष्ट नहीं थे या कॉलिंग कोड के लिए दृश्यमान नहीं हैं, तो GetManifestResourceStream null हो जाता है।

शुरू करने की जगह । इस बात का ध्यान रखें कि अपवाद कहां हुआ। उदाहरण के लिए

 try { // Do something to throw exception } catch (Exception e) { // Do something to handle exception throw e; // Wrong way! throw; // Right way } 

कॉल throw e; मामले में throw e; अपवाद कहां फेंका जाएगा इसकी जानकारी एक नई पंक्ति द्वारा प्रतिस्थापित की जाएगी, क्योंकि एक नया अपवाद बनाने से कॉल स्टैक साफ़ हो जाएगा। इसके बजाय, आपको एक throw; कॉल करने की आवश्यकता है throw; जो मूल अपवाद को फेंक देगा।

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

क्रमबद्धता। अपवादों को विरासत में मिला Exception बनाएं, जो सीरियल के साथ धारावाहिक हो। यह उपयोगी है क्योंकि यह पहले से कभी नहीं जाना जाता है जहां अपवाद प्राप्त होगा, उदाहरण के लिए, एक वेब सेवा में।

 [Serializable] public class SampleSerializableException : Exception { public SampleSerializableException() { } public SampleSerializableException(string message) : base(message) { } public SampleSerializableException(string message, Exception innerException) : base(message, innerException) { } protected SampleSerializableException(SerializationInfo info, StreamingContext context) : base(info, context) { } } 

मानक निर्माता । मानक निर्माणकर्ताओं को लागू करें, अन्यथा सही अपवाद हैंडलिंग मुश्किल हो सकती है। तो NewException को बाहर करने के लिए NewException ये निर्माता निम्नानुसार हैं:

• public NewException();
• public NewException(string);
• public NewException(string, Exception);
• protected or private NewException(SerializationInfo, StreamingContext);

---

MSDN, CodeProject, StackOverflow की सामग्रियों के आधार पर।