21acaf96   
   From: bouncer@dev.null   
      
   jens.muaddib@googlemail.com wrote:   
      
   > we are trying to develop a company standard hierarchy for exception   
   > handling in our software together with a small set of rules when to   
   > throw which exception. I thought that it would be a good idea to   
   > base our hierarchy on the standard exceptions and re-use the   
   > hierarchy from there, but we are having trouble to understand some   
   > of the standard exceptions and when to use which one. The standard   
   > is kind of short when describing the standard exceptions, it   
   > basically described the differences between runtime_error and   
   > logic_error. Derived exceptions are described very shortly in   
   > statements such as "The class invalid_argument defines the type of   
   > objects thrown as exceptions to report an invalid argument", which   
   > is kind of self-referencing. I am going to list some questions and   
   > interpretations in the following in the hope that some discussion   
   > could clarify things.   
      
   Forget it.  IMO, the standard exception hierarchy is close to   
   useless.   
      
   First, there is 'logic_error', which is based on the belief that it   
   makes sense to use exceptions to report errors in the program's logic.   
   C++ has a much better way of dealing with logic errors: emit a   
   diagnostic and abort.  The second-to-last thing we want on a logic   
   error is stack unwinding; the only one thing worse is trying to resume   
   business as usual after catching one.   
      
   That leaves the other half of the hierarchy: runtime_error.  That half   
   is, I think, meant for exceptions that couldn't reasonably be   
   anticipated.  The problem with std::runtime_error is that it holds a   
   std::string to store the error message, which implies you cannot   
   safely throw one when running out of resources.  The official   
   situation in C++11 seems to have improved somewhat, but in many   
   implementations, throwing a runtime_error is still equivalent to   
   risking a call to terminate() because of a double fault.   
      
   The only standard exception type left is std::exception.  All it can   
   do is return an implementation-defined pointer to a character array   
   that will hopefully tell us what went wrong.  That's, of course, a   
   reasonable start, but otherwise not very helpful for catching a more   
   specific type of exception and reacting appropriately.   
      
   In short: derive your exceptions from std::exception and make sure to   
   provide as sensible override for "const char *what() const throw()".   
   Other than that, I'm afraid you're on your own.   
      
   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)