From: use_my_alias_here@hotmail.com   
      
   >> Ok good, but how do you come to the conclusion that you want the root   
   >> cause at the /head/?   
   >   
   > It's like this: the initial operation requested by the "user" failed   
   > because of the root cause.  If the destructor hadn't thrown anything,   
   > that's what we'd hear about.  Secondary failures during cleanup are   
   > *typically* resource-release failures, which are *typically* fairly   
   > benign and of less interest to the caller; they don't describe why the   
   > requested operation failed.  Ignoring them might even be a reasonable   
   > approach.  So it doesn't seem reasonable to replace the head of the   
   > chain.   
   >   
      
   Ok, agree. The trick here will be to distinguish clean-up failures   
   related to the active exception and clean-up failures independent of the   
   active exception.   
      
      
   >> I claim that the most recent exception must be what is caught at the   
   >> next catch().   
   >   
   > I disagree.  Suppose you have a recovery action for the most recent   
   > exception, and you take it, and retry?  The original reason for failure   
   > persists, and the operation still fails.  Not good.   
   >   
      
   This is a tricky one. As you say, what's the point retrying if the root   
   cause persists? On the other hand, if we take a look a bit up in the   
   call stack, it's not likely that the code there will look for and catch   
   out-of-bounds exceptions caused a long road down the call stack.   
      
      
      
   >> That prioritization is not obvious and I claim it must not be left as   
   >> a side task.   
   >   
   > What do you mean by a "side task?"   
   >   
      
   I mean that in order to deal with secondary exceptions you must really   
   know what you are doing and have a firm coding convention to deal with   
   them, otherwise we risk unsafe exception handling when people start to   
   throw from destructors without knowing how to deal with the several   
   exceptions that might be generated.   
      
      
   > My plan is to leave it up to the author of the hook function for dealing   
   > with nested exceptions.  My claim is that "ignore secondary exceptions"   
   > might be a reasonable default, "chain the secondary exception to the   
   > first" might be better, "terminate" would be what you'd choose for   
   > absolute backward compatibility, and if you are are foolish enough to   
   > disagree with me about what should be at the head of the chain then   
   > you're free to do it the "wrong" way ;-)   
   >   
      
   I think we agree on most parts now, but I'm not sure that I've managed   
   to explain what I mean with independent failures.   
      
   There is a small risk, small but still a risk, that one destructor   
   throws a secondary exception for some completely independent reason when   
   another exception is active (some other function threw). Then "ignore   
   secondary exceptions" would be the same as   
      
   try   
   {   
      fnc();   
   }   
   catch( SecondaryException& )   
   {   
      // Swallow the secondary exception and do nothing!   
   }   
      
   I don't agree that it's a reasonable default.   
      
   That is what I meant with bulking. Somehow, you must be able to deal   
   with /multiple/ exception chains. Just putting a completely independent   
   secondary exception in the same chain as the active exception chain   
   will, in best case, lead to that the secondary exception is missed and   
   lost. In worst case, the application or person reading the log will   
   think it was part of the active failure and take action from that.   
      
      
   Allowing secondary exceptions may lead to something better, but I think   
   there must be some recommendations and guidelines how to use it.   
      
      
   Regards,   
   Daniel   
      
      
   --   
         [ 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)