अपवाद बनाम रिटर्न कोड - त्रुटि नियंत्रण के लिए लड़ाई

जाहिर है, हैबे पर अपवादों का सप्ताह सफलतापूर्वक आ गया है :)। कर्म का एक पर्याप्त "तकिया" जमा करने के बाद ताकि माइनस में जाने से डरो नहीं, मैं, शायद, इस मुद्दे पर भी अपनी राय व्यक्त करूंगा। तुरंत एक आरक्षण करें कि राय विशुद्ध रूप से व्यक्तिगत है, वाणिज्यिक विकास में थोड़ा व्यावहारिक अनुभव के आधार पर: सी ++, ऑब्जेक्टिव-सी, सी #, जावा, पायथन, रूबी।

गलती क्या है?

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

1. एक प्रोग्राम में होने वाली सबसे सरल चीज ऑपरेटिंग सिस्टम या हार्डवेयर की विफलता है। CreateEvent () या pthread_mutex_lock () सिस्टम कॉल जो काम नहीं किया, शून्य से विभाजन, सिस्टम कॉल के परिणामों में कचरा - यह सब विभिन्न कारणों से हो सकता है, सिस्टम में विफल हार्डवेयर से वायरस तक, लेकिन आमतौर पर हमारे और हमारे कार्यक्रम से यह बहुत निर्भर नहीं है।
2. थोड़ी अधिक जटिल स्थिति हमारे लिए आवश्यक संसाधनों की कमी है। अचानक, मेमोरी, हैंडल, फ़ाइल डिस्क्रिप्टर समाप्त हो सकते हैं। आवश्यक फ़ाइलों को लिखने या पढ़ने का कोई अधिकार नहीं हो सकता है। पाइप नहीं खुल सकता है। या इसके विपरीत - बंद न करें। डेटाबेस तक पहुंच हो भी सकती है और नहीं भी। ऐसी स्थिति पहले से ही हमारे कार्यक्रम (बहुत अधिक मेमोरी वांछित थी) और सिस्टम अस्थिरता (वायरस बहुत अधिक मेमोरी है) के कारण हो सकती है।
3. और सबसे आम स्थिति कार्यक्रम के तर्क या उसके भागों की बातचीत में एक गलती है। हम एक गैर-सूची सूची आइटम को निकालने की कोशिश कर रहे हैं, अमान्य तर्कों के साथ एक विधि को कॉल करते हैं और बहु-गैर-परमाणु ऑपरेशन करते हैं। एक नियम के रूप में, यह या तो कार्यक्रम के गलत व्यवहार की ओर जाता है ("टूलबार गायब हो गया है") या इसके उल्लंघन के साथ पहुंच क्रैश / अखंडित अपवाद।

जैसा कि आप देख सकते हैं, बहुत सारी भिन्न और बुरी चीजें हो सकती हैं - लेकिन यह पूरी सूची नहीं है :)। एक प्रोग्रामर को क्या करना चाहिए? यहाँ, मेरी राय में, हम एक बहुत ही रोचक और महत्वपूर्ण प्रश्न का सामना कर रहे हैं - हमारा कार्यक्रम इस या उस त्रुटि का वास्तव में क्या जवाब देता है? शायद अब मैं आपको एक बार फिर याद दिलाऊंगा कि मैं अपनी व्यक्तिगत राय व्यक्त कर रहा हूं। और मैं निम्नलिखित कहूंगा - किसी त्रुटि पर प्रतिक्रिया करने के लिए पूरी तरह से विशिष्ट कार्यक्रम पर निर्भर करता है। यदि हम ड्राइवर में मेमोरी से बाहर निकलते हैं, तो हमें हर कीमत पर जीवित रहना चाहिए ताकि उपयोगकर्ता को मौत की नीली स्क्रीन न मिले। यदि हम एक अजीब खेत की तरह खिलौने में स्मृति से बाहर निकलते हैं, तो यह गिरने, माफी मांगने और डेवलपर को एक बग रिपोर्ट भेजने के लिए समझ में आता है। रिबूट किए बिना कई महीनों तक स्पिन करने के लिए डिज़ाइन की गई एक सिस्टम सेवा को CreateEvent () त्रुटि के लिए सहानुभूति होनी चाहिए। फ़ोटोशॉप जैसे एप्लिकेशन प्रोग्राम में एक ही त्रुटि का अर्थ है कि सबसे अधिक संभावना है कि सिस्टम एक सेकंड में मर जाएगा, और त्रुटि को निगलने की कोशिश की तुलना में ईमानदारी से गिरना बेहतर है, उपयोगकर्ता को फ़ाइल को सहेजने दें और रिकॉर्डिंग के दौरान एक बाद की विफलता के कारण इसे सुरक्षित रूप से बर्बाद कर दें। इसलिए, हम त्रुटियों को अपेक्षित और अप्रत्याशित में विभाजित कर सकते हैं। विभिन्न कार्यक्रमों और विभिन्न आवश्यकताओं के लिए, एक ही त्रुटियों को अपेक्षित और अप्रत्याशित दोनों माना जा सकता है। हम किसी तरह अपेक्षित त्रुटियों के साथ काम कर रहे हैं। फ़ाइल नहीं खोल सका - हम उपयोगकर्ता से इस बारे में बात करते हैं और काम करना जारी रखते हैं। गीगाबाइट फ़ाइल अपलोड करने के लिए मेमोरी आवंटित करने में विफल - हम इस बारे में उपयोगकर्ता से बात करते हैं और काम करना जारी रखते हैं। ज्यादातर मामलों में, हम अप्रत्याशित त्रुटियों के साथ काम नहीं करते हैं। एक वस्तु बनाने के लिए बीस बाइट्स आवंटित करने की कोशिश करते समय स्मृति से बाहर - हम गिर जाते हैं। हमने एक सिस्टम ऑब्जेक्ट नहीं बनाया जिसके लिए पूरे कार्यक्रम में तीन टुकड़े हैं - हम गिर जाते हैं। सिस्टम पाइप जिसे विनिर्देश के अनुसार पढ़ा जाना चाहिए, पठनीय नहीं है? अस्थिर स्थिति में कार्यक्रम छोड़ने और फिर उपयोगकर्ता के डेटा को खराब करने की तुलना में गिरना बेहतर है। यदि वह कार्यक्रम को पुनरारंभ करता है, तो वह क्षतिग्रस्त फ़ाइल के लिए अपने दिनों के अंत तक नफरत करेगा। और गंभीर मामलों के लिए, एक ऑटोसैव है और अगर कुछ प्रहरी है तो हमें फिर से शुरू करना है।

अपवादों से पहले क्या हुआ था?

प्रक्रियात्मक प्रोग्रामिंग के दिन में, त्रुटियों के साथ काम करने के लिए वाक्यविन्यास तुच्छ था और इस पर आधारित था कि फ़ंक्शन क्या लौटा। यदि फ़ंक्शन TRUE लौटा है - सब कुछ ठीक है, लेकिन यदि FALSE - तो एक त्रुटि हुई है। उसी समय, त्रुटियों के साथ काम करने के दो दृष्टिकोण तुरंत सामने आ गए:

• दो-में-एक दृष्टिकोण - फ़ंक्शन FALSE या अशक्त सूचक दोनों अपेक्षित और अप्रत्याशित त्रुटियों के लिए देता है। यह दृष्टिकोण आमतौर पर सामान्य प्रयोजन एपीआई और उपयोगकर्ता कार्यक्रम कोड में लागू किया गया था, जब अधिकांश त्रुटियों को सुरक्षित रूप से घातक माना जा सकता था और दुर्घटनाग्रस्त हो गया था। उन दुर्लभ मामलों के लिए जब इसे साझा करना अभी भी आवश्यक था, फॉर्म की कुछ अतिरिक्त मशीनरी GetLastError () का उपयोग किया गया था। उस समय का एक कोड स्निपेट, एक फ़ाइल से दूसरी फ़ाइल में डेटा कॉपी करना और किसी भी समस्या के मामले में एक त्रुटि वापस करना:
  

  BOOL Copy( CHAR* sname, CHAR* dname )
  {
    FILE *sfile = 0, *dfile = 0;
    void* mem = 0;
    UINT32 size = 0, written = 0;
    BOOL ret = FALSE;
  
    sfile = fopen( sname, "rb" );
    if( ! sfile ) goto cleanup;
    dfile = fopen( dname, "wb" );
    if( ! dfile ) goto cleanup;
    mem = malloc( F_CHUNK_SIZE );
    if( ! mem ) goto cleanup;
    do
    {
      size = fread( sfile, mem, F_CHUNK_SIZE );
      written = fwrite( dfile, mem, size );
      if( size != written ) goto cleanup;
    }
    while( size )
    ret = TRUE;
  cleanup: //  .
    if( sfile) fclose( sfile );
    if( dfile) fclose( dfile );
    if( mem ) free( mem );
    return ret; //  .
  }
  

  
  
• , FALSE , ( error), . , apache, ( ) ( , 20 ). , ( FALSE) ( HANDLE).
  

  BOOL Copy( CHAR* sname, CHAR* dname, OUT HANDLE* error )
  {
    HANDLE sfile = 0, dfile = 0, data = 0;
    UINT32 size = 0;
  
    ENSURE( PoolAlloc() ); //     .
    ENSURE( FileOpen( sname, OUT& sfile, OUT error ) );
    REQUIRE( SUCCESS( error ) ); //     .
    ENSURE( FileOpen( dname, OUT& dfile, OUT error ) );
    REQUIRE( SUCCESS( error ) );
    ENSURE( MemAlloc( OUT& data ) );
    REQUIRE( SUCCESS( error ) );
    do
    {
      ENSURE( FileRead( sfile, F_CHUNK_SIZE, OUT& data, OUT error ) );
      REQUIRE( SUCCESS( error ) );
      ENSURE( FileWrite( dfile, & data ) );
      REQUIRE( SUCCESS( error ) );
      ENSURE( MemGetSize( OUT& size ) )
    }
    while( size );
    ENSURE( PoolFree() ); //      RAII.
    return TRUE;
  }
  

  
  

, , — .

, . (fopen, fclose) . (BOOL ret , ENSURE ) .

— . — , , . — if REQUIRE — . , :

• — — .
  

  void Copy( string sname, string dname )
  {
    file source( sname );
    file destination( sname );
    source.open( "rb" );
    destination.open( "wb" );
    data bytes;
    do
    {
      bytes = source.read( F_CHUNK_SIZE );
      destination.write( bytes )
    }
    while( bytes.size() )
  }
  

  
  
• — / nullable :
  

  bool Copy( string sname, string dname )
  {
    file source( sname );
    file destination( sname );
    if( ! source.open( "rb" ) || ! destination.open( "wb" ) ) return false;
    data bytes;
    do
    {
      bytes = source.read( F_CHUNK_SIZE );
      if( bytes.isValid() )
      {
        if( ! destination.write( bytes ) ) return false;
      }
    }
    while( bytes.isValid() && bytes.size() )
  }
  

  
  

?

, :). , . . . — . — - ? :

• , C++, . , . , .
• API . (checked) (unchecked), API , .
  
• « ». , , try catch , .

. , , — C++. « », « » « » C++. , API , . , — API , .