From: dave@boostpro.com   
      
   on Sun Jun 24 2012, Wil Evers  wrote:   
      
   > 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.   
      
   The reasons for implicit noexcept actually have nothing to do with a   
   bias against throwing from destructors, even though I'd be willing to   
   bet many committee members do have that bias.   
      
   > [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.   
      
   At heart, that's the same idea: account for the semantics of throwing   
   from dtors :-)   
      
   > 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?   
      
   Two things I can think of:   
      
   1. Removal of gratuitous brittleness.  In that sense, it's the same as   
      the deprecation of dynamic exception-specifications.  Programmers   
      shouldn't have to worry needlessly about gotchas.   
      
   2. Legitimacy for idioms like "throwing scopeguard"   
      
   > The idea that destructors are meant for automatic resource management   
   > is the key design principle behind RAII;   
      
   At this point what they were "meant for" is irrelevant; they're   
   primarily used that way, but they also get used for other things all the   
   time (e.g. logging at scope exit).   
      
   > 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?   
      
   The rules are already "broken." :-) It's time they were loosened.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)