From: mordor.nospam@fly.srk.fer.hr   
      
   On 2012-06-09, Thomas Richter  wrote:   
      
   > g++ at least in the version I tried (4.4.5) does not release objects   
   > on the heap when an exception is thrown in the destructor. The code   
   > simply doesn't go to the place where operator delete is called. In   
   > other words, you have a resource leak.   
      
   OK. Thanks for checking this.   
      
   > That's one of the many problems I have with the STL: Its   
   > inconsistency.  It would be ok to have a design which checks   
      
   I agree, inconsistency is a problem.  Out of curiosity, what other   
   problems do you have with the STL?   
      
   > So, for example, why does a division by zero *not* cause an   
   > exception?   
      
   Well, it does cause a CPU-exception.  Also, some CPUs (MIPS) don't   
   even check for division by zero; they just return an undefined result.   
   AFAIK, under Win32 you can convert OS-level exceptions to C++   
   exceptions.  (Definitely not portable.)   
      
   >> Depends.  Writing data to another location might be an option, for   
   >> example.   
   >   
   > Sure, but then this requires more knowledge than in the file object   
   > itself in first place. So which part of the object would you like to   
      
   Isn't this exactly the reason throwing an exception -- because you   
   can't handle the error locally?   
      
   > sound feasible to me - then we should rather keep the original and   
   > check *before* closing down. Copy of a FILE * or a file descriptor?   
   > Leaks implementation details.   
      
   Yes, a copy of the underlying OS-level object.   
      
   > IOW, I don't see why fclose() should then be any different from any   
   > other file operation to recover from. Make it explicit, so you can   
   > explicitly recover from it and you still have the object left you   
   > wanted to destroy in first place. If destruction can fail, the object   
   > that doesn't want to get destroyed must logically remain existent, and   
   > there is no way to realize this with destructors in C++ - it is the   
   > wrong mental model to have failing destructors.   
      
   I'm convinced.  So it seems that we can't have all of 1) RAII with   
   (arbitrary) cleanup in destructors, 2) consistently use exceptions   
   for error-reporting, and 3) reliability [as in: no errors are   
   ignored].   
      
      
   --   
         [ 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)