e047a545   
   From: PChapin@vtc.vsc.edu   
      
   On 2011-11-06 03:45, A. McKenney wrote:   
      
   >     It is much harder to write code that does _not_ leak resources if you   
   >     have to worry about exceptions.  Nobody had to worry about exception   
   >     safety before exceptions were introduced.  Exceptions simply added more   
   >     possible ways to leak resources, and ways which a lot more skill to deal   
   >     with.  It's much harder to control resources when virtually any line of   
   code   
   >     you write could potentially result in a branch to a location that won't   
   even be known   
   >     until run time.   
   >   
   >     Second, it seems a little arrogant to assume that you can judge the   
   competence of   
   >     programmers you have never met and whose problem areas you may have never   
   >     been aware even existed, simply on the basis of whether they use the   
   style   
   >     of programming you prefer.  There are situations where exceptions are a   
   bad   
   >     idea, regardless of how much elegance they might introduce.  There may   
   also   
   >     be business constraints.   
      
   There are definitely places where error codes make more sense, to me at   
   least, than exceptions. For example I find it generally quite awkward to   
   get an exception when a file fails to open. I usually want to handle   
   that error locally (or even ignore it) and dealing with exception   
   machinery in such a context is far less elegant than an old fashion if   
   statement. In short, failure to open a file just isn't that exceptional.   
      
   Also I worry about the strategy of putting catch-all handlers at the top   
   level of a program. Sure they can prevent the program from aborting and   
   allow the program to limp along, but is the program still in a good   
   state after the unexpected error? C++'s RAI idiom is great and really   
   helps control problems in this area... but can I be confident it has   
   been used consistently everywhere?   
      
   I'm not anti-exception, but I'm not sold on the idea that they are   
   inherently superior to error codes in every case. In fact, I think there   
   are many cases were error codes are probably better. Judgement needs to   
   be used when deciding which error reporting strategy to employ.   
      
   It is true that error codes are easy to ignore either accidentally or on   
   purpose. However, tool support can help with that. The SPARK/Ada tools   
   forbid the use of exceptions (too difficult to analyze statically) but   
   also forbid the programmer from ignoring values returned from   
   subprograms. If the programmer just tries to assign a value to dummy   
   variable, well, that causes an error as well. SPARK forbids assigning a   
   value that is subsequently never used. The net effect of this is that   
   you can't ignore error codes.   
      
   SPARK is designed for high integrity and safety critical programming so   
   its approach is reasonable in that context.   
      
   Peter   
      
      
   --   
         [ 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)