From: use_my_alias_here@hotmail.com   
      
   > IOW... exceptions or not, destructors or not, failure on a cleanup   
   > path is a no-win situation.   
   >   
   > So what do you do? You cheat, that's what! What does it mean? Well...   
   >   
   > 1. you make sure, to the best of your ability, to avoid failures on a   
   >     cleanup path; in the FILE example, you might want to reach for   
   >     (nonstandard) fpurge.   
   > 2. you   
   >     2.1 IGNORE cleanup failures   
   >     2.2 (or) merely report (log) them   
   >     2.2 (or) terminate on the spot (log first)   
   >   
   > You DON'T, EVER, try to "return" failure on a cleanup path, either   
   > through an exception, or a retval.   
   >   
   > Corollary: exceptions in a dtor DO NOT happen ;-).   
   >   
      
   I struggle convincing myself how to deal with clean-up. I guess I'm on par   
   with your ideas but I just can't find the clean wording for it. Right now I'm   
   into one idea related to the contract of the functions.   
      
   Let's say we have a File class and a method called writeData(). Also assume   
   that the File class could be implemented with our without caching the data to   
   write to disk. A direct call to the writeData() function is synchronous and   
   therefore the user    
   should be able consider the data as written on function return even though it   
   may be in a cache. So I agree with you that if we get problems syncing the   
   cache to disk from the destructor, we have a broken contract and a design   
   error.   
      
   If a cache must be used, a better design would be to provide an asynchronous   
   method called sendData() or something where the user at least knows that   
   everything may not have been written to disk unless confirmed so with some   
   isDataQueueEmpty() call.   
      
   I don't know the internals of close() but as someone pointed out; resource   
   release must be a no-fail operation. Until we have a no-fail close() we can't   
   use that reliably in the destructor.   
      
      
   /Daniel   
      
      
   --   
         [ 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)