From: bouncer@dev.null   
      
   Dave Abrahams wrote:   
      
   > on Mon Jun 25 2012, Wil Evers  wrote:   
   >   
   >> Dave Abrahams wrote:   
   >>   
   >>> 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).   
   >>   
   >> Agreed; it makes sense for such a destructor to throw if it fails   
   >> to update the log.  Of course, the repackaging you're proposing   
   >> does imply that the thrown exception cannot always be caught like   
   >> we're used to now,   
   >   
   > ? I don't understand what you mean.  Could you explain?   
      
   I think you suggested a user-installed handler that would be called   
   when a second exception escapes from a destructor invoked while   
   unwinding because of some other exception.  Such a handler can either   
   (1) terminate the program (which is the current state of affairs),   
   (2) propagate one of the exceptions while ignoring the other, or (3)   
   somehow link them together.   
      
   I'm worried about the way the calling code would be expected to deal   
   with either (2) or (3).  (2) implies that a thrown exception is lost,   
   while it seems to me that (3) could cause at least one of the   
   exceptions to bypass a catch block meant to handle it.   
      
   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)