2c348318   
   From: dave@boostpro.com   
      
   on Sat Nov 05 2011, "gast128-AT-hotmail.com"  wrote:   
      
   >> Writing exception-safe code is not about catching exceptions; it's about   
   >> maintaining invariants.   
   >   
   > I agree: this is the main issue and can be very difficult if your   
   > invariants span lots of cooperating classes.   
   >   
   >> If you're determined to go this way, there are some things you can do,   
   >> but none of them are what I'd call "elegant," and I don't think they   
   >> would solve your underlying problem, because merely changing the error   
   >> reporting system is not enough to get people to write code that handles   
   >> errors properly.  The very best thing you can do is to teach your people   
   >> how to handle errors while maintaining program invariants, and usually,   
   >> that job is actually easier to do with exceptions than with "err" codes.   
   >   
   > This is an old debate and from practical experience I have a less   
   > outspoken opinion about the last line.   
   >   
   > Using exception handling means that every 'error' must be handled   
   > otherwise the application terminates.   
      
   It's very easy to handle every error, though: just put a try/catch(...)   
   block in main.   
      
   > It effectively promotes every error to the fatal level.   
      
   Yes, but fatal for what?  It doesn't have to be fatal to the application   
   (see above).  The termination semantics of exceptions just mean they   
   terminate the current operation... which is almost always the right   
   default.   
      
   > With status return missed benign errors leave your application alive.   
      
   Which might be worse than termination.  It's usually the wrong default,   
   and it burdens programmers with explicitly ignoring errors all over the   
   place.   
      
   > Some people will flag that as 'undefined behavior', but that whole   
   > depends on the error context.   
      
   I'm not sure what you're talking about here, but it doesn't sound like   
   it has anything to do with undefined behavior as I understand it.   
      
   > This happens more than you think. We develop a 1 million line of data   
   > application with a heavy GUI. The GUI sometimes gets a little out of   
   > sync with the 'model' ('model' as in mvc). If every failed request   
   > would terminate the program, we would be out of business very soon.   
      
   Of course you don't terminate the program.  I don't tolerate things   
   getting "a little out of sync" in my code, but I can understand that you   
   may have a different practical reality to deal with.   
      
   > The failed query call on the model is an error, but for the whole   
   > application it doesnt need to be.   
      
   If you have a large category of conditions you're going to ignore (or   
   merely log, or something), you should put a wrapper around the operation   
   that catches and swallows/logs/whatever just those exceptions, but   
   should defintely *not* burden the programmer with an error code he's   
   supposed to ignore.  If someday you discover some odd circumstance in   
   which the error report is needed, you can always have the programmer use   
   the underlying API.   
      
   > Here status report works as good as exception handling (but you have   
   > to put catch handlers everywhere in the GUI).   
      
   If you're "putting catch handlers everywhere," there's something very   
   wrong somewhere.  That shouldn't be necessary.   
      
   > Another example I have was using the Boost.Filesystem. It throws an   
   > exception if it cannot open a file during directory iteration.   
   > I was developing a small tool to get a rough estimate of the directory   
   > size, but unfortunately a file was locked in that directory, resulting   
   > in a exception being thrown. Here one could argue that the application   
   > wasn't able to reach the end goal of calculating the directory size   
   > and so the exception was justified, but the goal was a rough estimate   
   > which is better than no estimate at all. I suppose u could argue if it   
   > is debatable if not being able to open a file is an 'error', but using   
   > exception handling certainly made it not ignorable anymore :(   
      
   I'm not sure that's a bad thing.  If you had wanted an exact result, the   
   exception would have been appropriate.  If you want a "rough estimate,"   
   you have to decide what that means, and decide what to do when a file   
   can't be opened.  Just ignoring an error is not necessarily enough to   
   make your result right for the job: should you assume this file is the   
   same size as the last one we had a size for?  Should you use zero for   
   the size?  Should you assume it's the same as the average of other   
   files?  So I don't see any justification for the frowny-face at the end   
   of that sentence.   
      
   --   
   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)