5b0bf412   
   From: bouncer@dev.null   
      
   Michael Kilburn wrote:   
      
   > On Jun 11, 7:35 pm, Wil Evers  wrote:   
   >> Michael Kilburn wrote:   
   >> > There is no workaround -- there is no way to determine if given   
   >> > dtor is called by stack unwinding or not.   
   >>   
   >> The obvious workaround is to put logic that may need to report an   
   >> exception in an explicitly called member function instead of in the   
   >> destructor.  I know that's not a perfect solution, which is why I   
   >> called it a workaround.  However, it is easy to understand and   
   >> implement, and not really that hard to use.   
   >   
   > i.e. special 'close()' function that needs to be called manually   
   > before every 'return' statement in given scope? It is like saying   
   > that RAII is not required: we have a workaround -- call cleanup   
   > manually.   
      
   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.   
      
   An important point is that the destructor remains responsible for   
   making sure no resources are leaked: it just checks if close() has   
   already been called, and cleans up if it hasn't.  But it never throws   
   an exception.   
      
   The reason this workaround isn't perfect is that the call to close()   
   becomes an inseparable part of the logic required to ensure the file's   
   contents are correct if no exception is reported.  Users who forget   
   that may not be notified if the file is corrupted.   
      
   IMO, this isn't really a language defect; it is caused by an inherent   
   problem in any delayed output scheme, and simply reflects the design   
   decisions embodied in the underlying API.   
      
   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)