home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,281 of 33,346   
   Zeljko Vrba to Joshua Maurice   
   Re: Developing an exception hierarchy   
   11 May 12 03:45:07   
   
   31eaa1a8   
   From: mordor.nospam@fly.srk.fer.hr   
      
   On 2012-05-10, Joshua Maurice  wrote:   
   >   
   > Code will have mistakes, and the question is what to do in the face of   
   > the mistakes. The wrong side says just write perfect code. The right   
   >   
   "Wrong" :-)  You have to (strive to) write perfect code if the end product is   
   to be linked in the same address space (e.g., C library, math library, etc).   
   For the sake of intellectual experiment, how would you write fault-tolerant   
   strchr(), or equivalent for std::string?   
      
   >   
   > PS: Sometimes it makes sense to me to return an error code for an   
   > unexpected condition. Then again, this is just semantic quibbling.   
   > What is an unexpected condition? Is a sanity check assert checking for   
   >   
   I would argue that unexpected conditions are all errors that might   
   conceivably happen but that you don't want to or don't know how to handle at   
   the point of failure.  Conditions that make it _impossible_ for the current   
   path to fulfill its postconditions.   
      
   For example: write() or close() of a file failing, getting an error while   
   acquiring/releasing a mutex, etc.  So instead of writing   
      
     close(fd);   
      
   and hoping all goes well (and never knowing when something goes wrong!),   
   you could write   
      
     if (close(fd) < 0) throw std::runtime_error("close()");   
      
   Postcondition was (presumably) properly formatted file, but if close() has   
   failed, you cannot guarantee that, hence -- throw exception.   
      
   But this perspective is incompatible with RAII: typically, you would wrap a   
   file or mutex in a class whose destructor would release the resource, but   
   throwing from a destructor is a big no-no.  So we have a mechanism for   
   reporting broken invariants (exceptions), but it is unusable if proper   
   destruction (e.g., successfully closed file or released mutex) is among   
   them.   
      
   Which gives?  Install a custom terminate handler and possibly longjmp()   
   out of it?   
      
      
   --   
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca