8f510d17   
   From: bouncer@dev.null   
      
   Michael Kilburn wrote:   
      
   > On Jun 13, 11:51 am, Wil Evers wrote:   
   >   
   >> Yes, the idea behind the usual workaround is to have a close()   
   >> member function that users who want an exception on an I/O error   
   >> from the underlying API should call before the object goes out of   
   >> scope.   
   >>   
   >> User code looks something like this:   
   >>   
   >> void save()   
   >> {   
   >> outfile f(/* ctor args */);   
   >> // ...write contents...   
   >> f.close();   
   >> }   
   >>   
   >> Since close() is never called from the stack unwinding machinery, it   
   >> can safely throw an exception.   
   >   
   > Let me change this sample for you:   
   >   
   > void save()   
   > {   
   > outfile f(/* ctor args */);   
   > // ...write contents...   
   > if (...)   
   > if (...) {...};   
   > else { ...; f.close(); return; }   
   > else   
   > if (...) { ...; f.close(); return; }   
   > /* etc */   
   >   
   > f.close();   
   [snip]   
   > }   
      
   No, let's keep both. Here's an edited version of yours, with the   
   problematic calls to f.close() removed, but still the same complicated   
   internal structure:   
      
   void write_contents(outfile& f)   
   {   
    if (...)   
    if (...) {...};   
    else { ...; return; }   
    else   
    if (...) { ...; return; }   
    /* etc */   
   }   
      
   And here's mine, slightly edited too. It just calls yours:   
      
    void save()   
    {   
    outfile f(/* ctor args */);   
    write_contents(f);   
    f.close();   
    }   
      
   Do we really need a language change for this? I rest my case.   
      
   Regards,   
      
   - Wil   
      
      
   --   
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|