From: 0xCDCDCDCD@gmx.at   
      
   On 07.11.2011 10:04, Peter C. Chapin wrote:   
   > On 2011-11-06 03:45, A. McKenney wrote:   
   >   
   >> ...   
   >   
   > 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.   
   >   
      
   Which API? I consider throw-always-on-failed-open to be a design error   
   for a general purpose file API.   
      
   > Also I worry about the strategy of putting catch-all handlers (...)   
   > 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?   
   >   
      
   This has little to do with exceptions. When *error codes are used*, how   
   can you, *for an exceptional error path*, be sure that the program is in   
   a valid state? Answer: You cannot! (And believe me, I'm working on a   
   code base that "doesn't use exceptions" and for the "exceptional cases"   
   the outcome of the program logic is often as muddled as you imply it   
   might be with exceptions.   
      
   But exceptions do have a upside: I can look at code and check whether it   
   is exception save (basic / strong / pick your flavour). After I   
   determined that, I can be "reasonably sure" that any exception-unwinding   
   will be gracefully handled.   
      
   With error codes, I have to hand-check every possible combination of   
   every possible error code combinations (and have to take into account   
   behaviour of possibly ignored errors).   
      
   > 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.   
   >   
      
   If you want and can handle an error code locally, then the error code   
   approach is better. Only then, IMHO. If an API forces you the catch an   
   "expected exception", the API is lacking.   
      
   cheers,   
   Martin   
      
   --   
   I'm here to learn, you know.   
   Just waiting for someone,   
   to jump from the shadows,   
   telling me why I'm wrong.   
      
      
         [ 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)