c# - एक विंडोज़ फॉर्म एप्लिकेशन में अपवाद हैंडलिंग के लिए सर्वश्रेष्ठ अभ्यास?




winforms exception-handling (10)

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

क्या कोई इस विषय पर ज्ञान के किसी मोती साझा करना चाहेगा? किसी भी सामान्य गलतियों को पोस्ट करें जो आपने अपने जैसे नए शौक देखे हैं, और इस तरह से अपवादों को संभालने पर कोई सामान्य सलाह है कि मेरा एप्लिकेशन अधिक स्थिर और मजबूत होगा।

मुख्य चीजें जो मैं वर्तमान में काम करने की कोशिश कर रहा हूं वे हैं:

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

सभी सलाह आभारी रूप से प्राप्त!


मुझे अपवाद को फिर से फेंकना चाहिए?

हर जगह, लेकिन अंत उपयोगकर्ता विधियों ... जैसे बटन हैंडलर क्लिक करें

क्या मुझे किसी प्रकार की केंद्रीय त्रुटि-प्रबंधन प्रणाली का प्रयास करने की कोशिश करनी चाहिए?

मैं एक लॉग फ़ाइल लिखता हूं ... WinForm ऐप के लिए बहुत आसान है

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

मुझे इस बारे में निश्चित नहीं है, लेकिन मुझे विश्वास है कि यह अपवादों को उखाड़ फेंकने का एक अच्छा अभ्यास है ... मेरा मतलब है कि आप पूछ सकते हैं कि कोई फ़ाइल मौजूद है या नहीं और यदि यह FileNotFoundException नहीं फेंकता है

क्या सभी निष्पादन योग्य कोड को अंततः ब्लॉक-प्रयास में संलग्न किया जाना चाहिए?

यीप

क्या कोई समय है जब खाली पकड़ ब्लॉक स्वीकार्य हो सकता है?

हां, मान लीजिए कि आप एक तारीख दिखाना चाहते हैं, लेकिन आपको कोई सुराग नहीं है कि उस तारीख को कैसे स्टोर किया गया था (डीडी / एमएम / वाईवाय, एमएम / डीडी / वाईय, इत्यादि) आप इसे टीपी पार्स करने का प्रयास करते हैं, लेकिन अगर यह विफल रहता है तो बस जारी रहें .. अगर यह आपके लिए अप्रासंगिक है ... मैं हाँ कहूंगा, वहां है


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

try
{
/*Doing stuff that may cause an exception*/
Response.Redirect("http:\\www.somewhereelse.com");
}
catch (ThreadAbortException tex){/*Ignore*/}
catch (Exception ex){/*HandleException*/}

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

अगर अपवाद वृद्धि को भी छोड़ दिया जाए तो फिर से फेंक न दें। कभी भी त्रुटियों को ध्यान न दें।

उदाहरण:

void Main()
{
  try {
    DoStuff();
  }
  catch(Exception ex) {
    LogStuff(ex.ToString());
  }

void DoStuff() {
... Stuff ...
}

यदि DoStuff गलत हो जाता है तो आप इसे किसी भी तरह से जमानत देना चाहते हैं। अपवाद मुख्य तक फेंक दिया जाएगा और आप पूर्व के स्टैक ट्रेस में घटनाओं की ट्रेन देखेंगे।


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

यही कारण है कि आपको कभी भी गर्भ धारण नहीं करना चाहिए और सोचें कि आपके ऐप में कोई बग नहीं है, इसकी गारंटी नहीं है। और उचित कोड के बारे में कुछ कोशिश करने वाले ब्लॉक को लपेटने और त्रुटि संदेश दिखाने / त्रुटि लॉग करने के लिए यह बहुत ही छोटा प्रयास है।

एक उपयोगकर्ता के रूप में, जब भी कोई ब्राउज या ऑफिस ऐप या जो भी दुर्घटनाग्रस्त हो जाता है, तो निश्चित रूप से मुझे गंभीरता से परेशान हो जाता है। यदि अपवाद इतना ऊंचा है कि ऐप जारी नहीं रख सकता है तो उस संदेश को प्रदर्शित करना बेहतर होगा और उपयोगकर्ता को बताएं कि क्या करना है (पुनरारंभ करें, कुछ ओएस सेटिंग्स को ठीक करें, बग की रिपोर्ट करें, इत्यादि) बस दुर्घटनाग्रस्त होने की तुलना में और यही वह है।


कुछ और बिट्स ...

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

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

जब आप बिल्कुल सही होते हैं, तो सबसे अच्छी तरह से प्रलेखित मामलों को छोड़कर, कभी भी "अपवाद" न करें, सकारात्मक रूप से सुनिश्चित करें कि अपवाद को फेंक दिया जा सकता है। यह लगभग मामला कभी नहीं होगा। (और यदि यह है, तो सुनिश्चित करें कि आप केवल विशिष्ट अपवाद वर्ग निगल रहे हैं - System.Exception कभी भी System.Exception । अपवाद।)

जब पुस्तकालयों का निर्माण (आपके ऐप द्वारा उपयोग किया जाता है), अपवादों को निगलें, और अपवादों को बुलबुला करने से डरो मत। जब तक आपके पास जोड़ने के लिए कुछ उपयोगी न हो तब तक फिर से फेंक न दें। कभी नहीं (सी # में) ऐसा करें:

throw ex;

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

throw;

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

.NET में अपवाद हैंडलिंग विज्ञान की तुलना में अधिक कला है। यहां सभी को साझा करने के लिए उनके पसंदीदा होंगे। ये केवल कुछ सुझाव हैं जिन्हें मैंने 1 दिन से .NET का उपयोग करके उठाया है, तकनीकें जिन्होंने एक से अधिक अवसरों पर अपने बेकन को बचाया है। आपकी माइलेज भिन्न हो सकती है।


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

अनचाहे अपवाद संवाद को प्रदर्शित करने के लिए और लॉगिंग के लिए ऐसे अपवादों को पकड़ने के लिए और / या अपना स्वयं का त्रुटि संवाद प्रदान करने के लिए आप एप्लिकेशन से कॉल कर सकते हैं। अपने मुख्य () विधि में एप्लिकेशन.रुन () पर कॉल से पहले।


मैं इस नियम के बारे में गहराई से सहमत हूं:

  • कभी भी त्रुटियों को ध्यान न दें।

कारण यह है कि:

  • जब आप पहली बार कोड लिखते हैं, तो संभवतः आपके पास 3-पक्ष कोड, .NET FCL lirary, या आपके सहकर्मियों के नवीनतम योगदान का पूर्ण ज्ञान नहीं होगा। हकीकत में आप तब तक कोड लिखने से इंकार नहीं कर सकते जब तक आप हर अपवाद की संभावना को अच्छी तरह से नहीं जानते। इसलिए
  • मुझे दृढ़ता से पता चलता है कि मैं कोशिश / पकड़ (अपवाद पूर्व) का उपयोग करता हूं क्योंकि मैं खुद को अज्ञात चीज़ों से सुरक्षित रखना चाहता हूं, और जैसा कि आपने देखा है, मैं अपवाद पकड़ता हूं, अधिक विशिष्ट नहीं जैसे आउटऑफमेमरी एक्सेप्शन इत्यादि। और, मैं हमेशा अपवाद करता हूं ForceAssert.AlwaysAssert (झूठी, ex.ToString ()) द्वारा मुझे (या क्यूए) तक पॉप अप किया जा रहा है;

ForceAssert.AlwaysAssert Trace.Assert का मेरा व्यक्तिगत तरीका है, भले ही DEBUG / TRACE मैक्रो परिभाषित किया गया हो।

विकास चक्र शायद: मैंने बदसूरत आवेषण संवाद या किसी और ने इसके बारे में शिकायत की है, तो मैं कोड पर वापस आ गया हूं और अपवाद बढ़ाने और इसे संसाधित करने का निर्णय लेने का कारण समझता हूं।

इस तरह से मैं थोड़े समय में अपना कोड लिख सकता हूं और मुझे अज्ञात डोमेन से सुरक्षित कर सकता हूं, लेकिन असामान्य चीजें होने पर हमेशा ध्यान दिया जा रहा है, इस तरह से सिस्टम सुरक्षित और अधिक सुरक्षा प्राप्त करता है।

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

WinForms कोड के लिए, मैं हमेशा एक सुनहरा नियम मानता हूं:

  • हमेशा अपने ईवेंट हैंडलर कोड को आज़माएं / पकड़ें (अपवाद)

यह आपके यूआई को हमेशा उपयोग करने योग्य बनाएगा।

प्रदर्शन हिट के लिए, प्रदर्शन जुर्माना तब होता है जब कोड पकड़ता है, वास्तविक अपवाद के बिना प्रयास कोड निष्पादित करने का कोई महत्वपूर्ण प्रभाव नहीं पड़ता है।

अपवाद थोड़ा मौका के साथ किया जाना चाहिए, अन्यथा यह अपवाद नहीं है।


मैं बस अपने रास्ते पर हूं लेकिन अपवाद हैंडलिंग का उपयोग करने के लिए आपको एक संक्षिप्त रन दे दूंगा। जब मैं वापस आऊंगा तो मैं आपके अन्य बिंदुओं को संबोधित करने का प्रयास करूंगा :)

  1. सभी ज्ञात त्रुटि स्थितियों के लिए स्पष्ट रूप से जांच करें *
  2. यदि आप अनिश्चित हैं तो आप कोड के चारों ओर एक कोशिश / पकड़ जोड़ें यदि आप सभी मामलों को संभालने में सक्षम थे
  3. कोड के चारों ओर एक कोशिश / पकड़ जोड़ें यदि आपके द्वारा कॉल किए जा रहे .NET इंटरफ़ेस को अपवाद फेंकता है
  4. कोड के चारों ओर एक कोशिश / पकड़ जोड़ें यदि यह आपके लिए जटिलता सीमा पार करता है
  5. यदि सैनिटी चेक के लिए कोड के चारों ओर एक कोशिश / पकड़ जोड़ें: आप यह कह रहे हैं कि कभी नहीं होना चाहिए
  6. एक सामान्य नियम के रूप में, मैं अपवादों का उपयोग रिटर्न कोड के प्रतिस्थापन के रूप में नहीं करता हूं। यह .NET के लिए ठीक है, लेकिन मुझे नहीं। मेरे पास इस नियम के अपवाद हैं (हेहे) हालांकि, यह उस एप्लिकेशन के आर्किटेक्चर पर निर्भर करता है जिस पर आप काम कर रहे हैं।

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

मैं एक के लिए भारी अपवाद आधारित आर्किटेक्चर से दूर चलने के लिए प्रवृत्त होते हैं। कोशिश / पकड़ में प्रदर्शन प्रदर्शन नहीं होता है, हिट तब आती है जब अपवाद फेंक दिया जाता है और कोड को कॉल करने के पहले कॉल स्टैक के कई स्तरों पर चलना पड़ सकता है।


यहां कुछ दिशानिर्देश दिए गए हैं जिनका मैं अनुसरण करता हूं

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

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

  3. उन अपवादों को न पकड़ें जिन्हें आप संभाल नहीं सकते हैं, इसलिए OutOfMemoryException जैसी चीजों के बारे में चिंता न करें क्योंकि यदि वे होते हैं तो आप वैसे भी बहुत कुछ करने में सक्षम नहीं होंगे।

  4. वैश्विक अपवाद हैंडलर हुक करें और जितना संभव हो उतना अधिक जानकारी लॉग इन करना सुनिश्चित करें। Winforms हुक के लिए दोनों एपडोमेन और थ्रेड अपवादित घटनाओं unhandled।

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

  6. निश्चित रूप से ऐसे समय होते हैं जब खाली पकड़ ब्लॉक की आवश्यकता होती है, मुझे लगता है कि जो लोग अन्यथा कहते हैं वे कोडबेस पर काम नहीं करते हैं जो कई रिलीज पर विकसित हुए हैं। लेकिन उन्हें यह सुनिश्चित करने के लिए टिप्पणी की जानी चाहिए कि उनकी वास्तव में आवश्यकता है। सबसे आम उदाहरण डेवलपर्स को ParseInt () का उपयोग करने के बजाय स्ट्रिंग को पूर्णांक में बदलने के लिए प्रयास / पकड़ का उपयोग कर रहा है।

  7. यदि आप अपने कोड के कॉलर को त्रुटि स्थितियों को संभालने में सक्षम होने की अपेक्षा करते हैं तो कस्टम अपवाद बनाएं जो बताएं कि अप्रत्याशित स्थिति क्या है और प्रासंगिक जानकारी प्रदान करती है। अन्यथा बस जितना संभव हो सके अपवाद प्रकारों में बने रहें।


यहां पोस्ट की गई सभी सलाह अच्छी और उचित है।

एक चीज जिस पर मैं विस्तार करना चाहता हूं वह आपका प्रश्न है "क्या अपवादों को संभालना है जो पूर्व-निष्पादित परीक्षण चीजों की तुलना में एक प्रदर्शन हिट कर सकते हैं जैसे कि डिस्क पर एक फ़ाइल मौजूद है?"

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

उदाहरण के लिए, यदि आप एक शब्दकोश पॉप्युलेट कर रहे हैं, तो यह:

try
{
   dict.Add(key, value);
}
catch(KeyException)
{
}

ऐसा करने से अक्सर तेज़ होता है:

if (!dict.ContainsKey(key))
{
   dict.Add(key, value);
}

आप जो भी आइटम जोड़ रहे हैं, उसके लिए अपवाद केवल तभी फेंक दिया जाता है जब आप डुप्लिकेट कुंजी जोड़ रहे हों। (LINQ कुल प्रश्न यह करते हैं।)

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

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







exception-handling