From: 0xCDCDCDCD@gmx.at   
      
   On 05.06.2012 03:48, Francis Glassborow wrote:   
   > On 04/06/2012 13:46, DeMarcus wrote:   
   >> Hi,   
   >>   
   >> There is always a big discussion about exceptions and when and   
   >> where they can be thrown.   
   >>   
   >> In Exceptional C++ by Herb Sutter, p.55, he states why throwing   
   >> from destructors is a bad thing. Apparently for a lot of people in   
   >> the community (including myself) it has been difficult to be   
   >> convinced that the bad thing with throwing from a destructor is   
   >> more than just an unsolved technical detail.   
   >>   
   >   
   > From my perspective it is more than that. Once the body of a dtor   
   > has been entered the object's lifetime has ended. Now what happens   
   > when you throw from a dtor? The object is dead but has not been   
   > properly buried.  How is the clean up supposed to happen?   
   >   
   > I once thought throwing from a dtor was fine but as I came to think   
   > about it I came to realise that if something happens within a dtor   
   > that means that it is not possible to complete the clean-up then the   
   > process needs something much more drastic than throwing an   
   > exception. Exceptions are designed to pass problems from the place   
   > where they can be detected to the place where they can be dealt   
   > with, but how can that apply to a dtor, either you can handle the   
   > problem locally or the problem cannot be handled but can only be   
   > ignored.   
   >   
      
   I think this view is too narrow.   
      
   The main problem is that in C++ dtors serve double duty.   
   * They are used for (resource) cleanup   
   * They are used as generic at-scope-exit callbacks   
   * And sometimes, they are used for *both* duties at once.   
      
   Personally, I haven't seen a convincing example of where pure resource   
   cleanup can fail meaningfully.   
      
   On the pother hand, for me the standard example of a mixed case are   
   DB-connections and file classes. Their destructors conveniently close   
   the file/the connection, but closing such a resource often involves   
   either a "flush" or a "commit", both operations that may well fail,   
   fail legitimately, and the failure of which itself may well be best be   
   reported directly by an exception.   
      
   The flush/commit has *nothing* to do with resource cleanup, but it is   
   an integral part of "closing" such an object, and since you cannot   
   keep the object "open" when it's destructed, there's really nothing to   
   do but do a "close", including the "flush" in the dtor.   
      
   Personally I think it may well be possible and also good theory to   
   separate these concerns and require "files" to always be "closed"   
   explicitly prior to destruction. It just becomes impractical and   
   additionally, people would then go and use a scope-guard like   
   mechanism where the close/flush would be done explicitly in a   
   destructor of the scope-guard object.   
      
   I think that most people would agree that given how exceptions and   
   stack unwinding work together in C++, there is little that can be   
   meaningfully done in the face of double-exceptions, but somehow I feel   
   the cases where operations in a destructor can fail are legitimate and   
   somehow there doesn't seem to be much help from the language or in the   
   form of common wisdom on what to do with the legitimate cases.   
      
   std::uncaught_exception is certainly of only little help (also see   
   http://www.gotw.ca/gotw/047.htm).   
      
   cheers,   
   Martin   
      
      
   --   
   I'm here to learn, you know.   
   Just waiting for someone,   
   to jump from the shadows,   
   telling me why I'm wrong.   
      
      
         [ 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)