From: use_my_alias_here@hotmail.com   
      
   > 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.   
      
   Ok, I start to understand. Put all resources in their own managed RAII   
   objects.   
      
   >> You may be able (even with current C++) to queue up exceptions in a   
   >> destructor, chain them all in the end of the destructor and   
   >> throw. Now you have solved the resource release problem but most   
   >> certainly the destructor will have undetermined behavior since code   
   >> after an exception should not be executed.   
   >   
   > What do you mean by "undetermined behavior?"  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.   
      
   My undetermined behavior idea will be obsolete with managed resources,   
   so I skip explaining that further.   
      
   >> The exception chaining will chain every exception it   
   >> encounters. The idea (as I see it) with chaining is that you should   
   >> be able to follow the exception and what caused it, look at its   
   >> parent exception in the chain and its parent to finally see the   
   >> root cause. This could be good in a logging system.   
   >   
   > Actually, we plan to propose a handler (like the standard unexpected   
   > handler) that can do anything it wants with the secondary exception,   
   > including logging or chaining it.  And if you do chain it, the root   
   > cause of unwinding should stay at the head of the chain.   
      
   Ok good, but how do you come to the conclusion that you want the root   
   cause at the /head/?   
      
   Let's say you get an out-of-bounds exception, someone catches it and   
   chains it with an XML-error exception, throws that to someone that   
   catches it and chains it with a PreferenceFile-read-error exception and   
   throws that. What is the catcher of that chained exception going to do   
   with an out-of-bounds exception?   
      
   I claim that the most recent exception must be what is caught at the   
   next catch().   
      
   >> Now if you are unfortunate, a destructor during unwinding may throw   
   >> an exception that is independent of the active exception, but will   
   >> still be part of the chain, causing confusion if the whole chain is   
   >> written to a log.   
   >   
   > Reading logs is not for the faint-of-heart already.  I don't see how   
   > this is going to make anything worse.   
      
   You have convinced me that managed resources solve resource leaks but   
   I'm still not convinced about the independent exceptions. Strong-heart   
   people may be able to read cryptic logs (not that I would prefer that)   
   but how are they going to be able to choose which of the independent   
   exceptions shall take the head in the chain?   
      
   >> That is what I meant with bulking exceptions. Bulking is a pure   
   >> hypothetical non-C++ way of bulking up several exception chains to   
   >> be thrown if several unrelated problems arises during unwinding. As   
   >> I write I think it may even be feasible to have a main exception   
   >> that contains a list of exception chains, but we will still suffer   
   >> from resource leaks or undefined behavior.   
   >   
   > No, those are imaginary problems, unless you choose to both   
   >   
   > a) throw from your destructor, and   
   > b) ignore the specified semantics of throwing from destructors   
      
   We agree on a), but in b) the specified semantics would involve   
   prioritizing one independent exception from another. That   
   prioritization is not obvious and I claim it must not be left as a   
   side task.   
      
      
   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)