From: dave@boostpro.com   
      
   on Tue Jun 05 2012, Zeljko Vrba  wrote:   
      
   > My view is that exceptions are a way of reporting inability to   
   > fulfill invariants,   
      
   s/invariants/postconditions/, please.   
      
   > and I'm rather convinced that this is the only useful way of talking   
   > about exceptions as it also seems to be the only way of avoiding   
   > long discussions about what qualifies as exceptional condition.   
   >   
   > You can choose to report broken promises with some variant of return   
   > codes or with exceptions.   
   >   
   > The real question is: should destructors be used to enofrce   
   > invariants?   
      
   Example, please.  Do you have in mind an invariant like, "every file   
   used by the program is either closed or associated with some live   
   object of type File?"   
      
   It's only an invariant if it is truly invariant.  If you can't   
   guarantee that close() will succeed then you'd better not state an   
   invariant like the one above, because it's a promise you can't keep.   
   When designing contracts, brutal honesty is a hard requirement.   
      
   > If yes, how do you report inability to fulfill invariants?   
      
   You don't.  If your invariants are broken your program is broken and   
   can't do *anything* reliably, because the whole program has been   
   written with the assumption that stated invariants hold.  In other   
   words, if you can find no choice other than to leave some stated   
   invariant broken, it is time to terminate the program.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)