68cf6b4b   
   From: bouncer@dev.null   
      
   Agents Marlow wrote:   
      
   > On May 9, 11:03 pm, Wil Evers  wrote:   
      
   >> 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.   
   >   
   > That is not acceptable in some situations. I worked on a very large   
   > server app where each function offered by the server was relatively   
   > isolated.  With your approach a logic error in one server function   
   > would bring down the entire server and severe the connection to all   
   > its clients.  So that our function never did this we used an   
   > exception that meant 'an assertion has failed'. It inherited from   
   > std::logic_error.  We caught it at the entry to our function, where   
   > we reported it then exited our function. Users would report that   
   > their command failed but the server itself did not fail.   
      
   That seems very brittle to me.  A logic_error reports a problem is the   
   program's logic; it doesn't say the error's effects are limited to the   
   state of the current connection.   
      
   Unless you control all of the program's code, there is no way to know:   
   the logic_error could have been thrown from your own code, or -   
   because it is a standardized exception type - from some third-party   
   component that is unaware of your interpretation.   
      
   The way to be sure is to somehow distinguish between exceptions that   
   are known to be locally recoverable from the rest; a straightforward   
   approach would be to use a dedicated exception type, different from a   
   plain logic_error, for that.   
      
   >> That leaves the other half of the hierarchy: runtime_error.  That   
   >> half is, I think, meant for exceptions that couldn't reasonably be   
   >> anticipated.   
   >   
   > Hmm. File not found, database connection lost, insufficient   
   > resources, etc are all examples of runtime errors. These can be   
   > expected to occur but they are not usually part of the 'happy   
   > path'. They still need to be catered for.  For any that specifically   
   > need to be catered for, maybe several levels higher up, I would use   
   > an application exception that inherits from std::runtime_error.   
   >   
   >> 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.   
   >   
   > Almost. You cannot safely throw one when running out of memory. But   
   > when that happens std::bad_alloc tends to get thrown.   
      
   I wouldn't bet on that.  At least for C++03, both the expert community   
   and some common C++ implementations disagreed on what is supposed to   
   happen when the program runs into an exception while initializing the   
   object carrying the value of a throw-expression.  Some thought this   
   should result in a call to terminate(), while others advocated   
   propagating the exception that caused the initialization of the   
   exception object to fail.   
      
   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)