From: bouncer@dev.null   
      
   Dave Abrahams wrote:   
      
   > I think chances are good that it will be fine to throw from   
   > destructors.  In fact, I intend to submit a proposal to make it so.   
      
   That's an interesting development, to say the least.  It's also kind   
   of surprising: by introducing the implicit noexcept in C++11, the   
   committee seems to have been moving away from the idea of throwing   
   exceptions from destructors.   
      
   [snip]   
      
   > There's no new "resource leak problem."  Anytime you have an   
   > un-managed resource you have to watch out for exceptions.  Any   
   > resources managed directly by an object become un-managed when you   
   > enter the destructor body.  Either don't throw an exception from   
   > destructors of such objects (status quo), or (better) delegate   
   > resource management to a sub-object.   
      
   [snip]   
      
   > The behavior of dtors in the presence of exceptions is   
   > well-specified, and actually pretty reasonable: when not already   
   > unwinding, the rest of the current dtor's body is skipped but all of   
   > the other sub-objects are destroyed as part of unwinding.  If you   
   > don't like that behavior, well, don't throw from your destructor.   
   > But if you want to throw from your destructor you can easily work   
   > with these semantics to get a useful "determined" result.   
      
   Agreed.  Another idea would be to only throw from a destructor body   
   after any directly owned resources have been released.  In any case,   
   what we're doing here is making sure the destructor still keeps its   
   promise to release any resources, even if it reports an exception.   
      
   But that immediately raises a question: if the destructor is able to   
   meet that obligation, then why does it need to throw an exception?  It   
   can only mean that the destructor is expected to do more than just   
   resource management.   
      
   And that, I think, is the heart of the matter: is it a good idea to   
   change the language to provide better support for these other uses?   
   Even if it is technically feasible to do so, what will we gain?   
      
   The idea that destructors are meant for automatic resource management   
   is the key design principle behind RAII; the idea that destructors   
   don't throw is a hard requirement in many parts of the standard   
   library, and I suspect lots of user code is based on these assumptions   
   too.  Why make it easier to break the rules?   
      
   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)