From: jklowden@speakeasy.net   
      
   On Fri, 18 May 2012 17:28:06 -0700 (PDT)   
   Wil Evers  wrote:   
      
   > It is close()'s surprising double-duty nature that causes the problem   
   > we're discussing here.  Destructors are compiler-generated callbacks   
   > that tell us to release our resources; they were simply not designed   
   > for anything else.   
      
   Exceptions don't exist to tell us to free resources.  Exceptions exist   
   to report problems.  They're a big step forward from simply returning   
   an error code and trusting every caller to DTRT.   
      
   I don't see anything special about performing, or failing to perform,   
   I/O in a destructor.  I don't see what all the fuss is about.  Any I/O   
   can fail, and any exception can be caught.  Or, if not caught, at least   
   reported.  And, hopefully, seen.   
      
   > For example: it is a bad idea to allocate memory in a destructor,   
   > unless of course you're prepared to handle an out-of-memory situation   
   > locally, without an exception escaping.   
      
   And yet the standard exception classes allocate memory.  Even if they   
   didn't, what's to assure there's room on the stack to instantiate the   
   object to be thrown?  What about a failing drive, an uncorrected memory   
   error, flaky power supply, or any other of myriad improbable,   
   unavoidable, unrecoverable failure conditions?  What about a blackout   
   that wipes out the whole east coast of the United States for the better   
   part of a week?   
      
   In the great scheme of things ISTM failing to allocate a string on the   
   heap is the least of our worries.   
      
   Unless you have total control over all the software in your system *and*   
   all the software surrounding it -- surely the exception these days -- a   
   low memory situation will trigger a plethora of bugs in mostly   
   untested code. The odds of landing on its feet are roughly nil.   
      
   Which is fine, sort of, because it has to be.  It's only software.  The   
   consequences of ending in a bad way are merer than getting a bad   
   haircut.   Because hair, after all, unlike machine state, is   
   nonrecoverable and cannot be duplicated.   
      
   --jkl   
      
      
   --   
         [ 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)