From: bouncer@dev.null   
      
   Dave Abrahams wrote:   
      
   > on Thu Jun 07 2012, Wil Evers  wrote:   
      
   >> However, so far, nobody has come up with a convincing idea about   
   >> what should happen when that destructor is invoked, either directly   
   >> or indirectly, from the stack unwinding machinery.  Which is why I   
   >> suspect the problem is more fundamental, and related to the   
   >> semantics we associate with destructors.   
   >   
   > Meh.  I think it's pretty obvious that you can continue with the   
   > exception that's currently unwinding.  That's the one aborting the   
   > current operation.  Trust the programmer: a class that is throwing   
   > from its destructor is presumably written to be "properly destroyed"   
   > (whatever that means) once the lifetime of the whole object ends,   
   > even if the destructor throws.  IMO it would be fine if the second   
   > exception had the current semantics for destructors that throw   
   > not-during-unwinding, if we discarded that second exception (or   
   > chained it, a la std::nested_exception, to the one that's unwinding)   
   > once the lifetime of the complete object whose dtor threw had ended.   
      
   That is a indeed a convincing idea, although having to say something   
   like "yes, you did throw an exception, and no, it was not reported in   
   the usual way; it was discarded/repackaged because of some other,   
   possibly unrelated failure" does seem awkward.  But then, some of the   
   alternatives are at least as awkward.   
      
   The only thing that sounds less awkward to me is simply accepting that   
   destructors are not supposed to report errors.   
      
   - 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)