From: bouncer@dev.null   
      
   Dave Abrahams wrote:   
      
   > on Tue Jun 26 2012, Wil Evers  wrote:   
      
   >> 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.   
   >   
   > Exactly   
   >   
   >> 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.   
   >   
   > Meh.   
   >   
   > The information in an exception is very rarely of much importance to   
   > the correct functioning of a program; if an exception is already in   
   > flight, the same unwinding path will be followed at least until such a   
   > time as the exception needs to be reported or translated.   
      
   I disagree.  Consider, for example, a loop that listens on a network   
   connection for incoming request messages, answering each with a   
   corresponding reply message. In such a loop, some exceptions (such as   
   a syntax error in the request) can be handled by simply answering with   
   an error reply, while other exceptions (such as a failure to allocate   
   enough buffer space to compose a valid reply) are so serious that the   
   loop needs to be exited and the connection closed.   
      
   >From experience, I can assure you that the critical task of determining   
   the proper cause of action here can get quite hairy, even with today's   
   exception semantics.  That will only get harder if we have to take   
   either lost exceptions (the (2) above) or exceptions reported as linked   
   to some other exception (the (3) above) into account.   
      
   In short, it seems to me your proposal trades complexity on the   
   throwing side for complexity on the catching side.  That may very well   
   be a reasonable tradeoff, but at the very least, we should be aware of   
   its pros and cons.   
      
   - 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)