e047a545   
   From: ulrich.eckhardt@dominolaser.com   
      
   Am 06.11.2011 09:45, schrieb A. McKenney:   
   > Francis Glassborow wrote:   
   >> ... Yes you can do it all with error codes but I will bet that any   
   >> programmer who wants to use error codes instead of exceptions will   
   >> write code that leaks like a sieve (and the leaks will not just be   
   >> memory but scarce resources as well)   
   >   
   > I would argue the opposite.   
   >   
   > 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.   
      
   If you use the spirit behind RAII consequently, you can return from any   
   line of code just as you can throw from any line of code and no   
   resources are leaked. It's just that you need to put the resource   
   management in the hands (read: constructor and destructor) of types that   
   explicitly guarantee the according policy.   
      
      
   > 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.   
      
   When I write   
      
      auto_ptr f(new Fou);   
      
   I code the whole resource management information concerning "f" into a   
   single line. I declare that the Fou shall be destroyed when it reaches   
   the end of the scope, unless it is given to another owner (e.g. by   
   returning from the function, passing it as parameter or simply   
   assignment). This single line contains all these orders, and the rest of   
   the function will obey them, without a further line of code to write. In   
   particular without any further line which could be skipped or forgotten   
   to be written!   
      
   This has incredible advantages, not just for code with exceptions,   
   because all this is coded on a single line. If you code your resource   
   management like this, you get basic exception safety for free.   
      
   Concerning the "commit or rollback" part of exception safety, this   
   requires a bit more care, but the same care would be needed when you are   
   using errorcodes. Actually, using error codes, it would be even more   
   complicated, because of all the error-handling code mixed with the   
   application logic.   
      
      
   >> There is a great deal more to replacing exceptions with error codes   
   >> and most of it is tedious hard work. (It is much easier to go the   
   >> other way)   
   >   
   > Well, if  you are trying to translate what a 3rd party library treats   
   > as error conditions into something that expresses their significance   
   > to the application, it's going to be tedious hard work, regardless of   
   > whether one uses exceptions or error codes.  What the library   
   > developer considered end-of-the-world errors may turn out to be   
   > something that the application that uses it can freely ignore, and   
   > vice versa, as has already been pointed out in this thread.   
      
   I tend to disagree here. The code throwing the exception never knows   
   what influence the failure has for the embedding application. All that   
   the throwing code knows that it has encountered a condition where it   
   can't continue. As such, a library also doesn't attach any importance   
   level to the error, it just reports the failure. It is then up to the   
   caller to decide what to do and the (IMHO reasonable) default assumption   
   is that the operation was attempted because it was important, so if it   
   fails we can't continue either, so the exception is propagated up the   
   call stack.   
      
      
   BTW: If you are consequent about the non-exception part, you loose quite   
   a few things:   
   1. std::containers   
   All std::containers use exceptions for signalling error conditions, even   
   from their constructors.   
   2. constructors   
   Any constructor that can fail needs to be rewritten to remember the   
   fault, i.e. every such class gets a "valid" flag which must be verified   
   after construction. You still don't know what went wrong, for that you   
   would have to store the errorcode, but at least you know the object is   
   broken. This flag needs to be checked in several places, in particular   
   the destructor.   
   3. operator overloading   
   For strings, operator+ requires allocation and subsequently can fail.   
   The best way out of this is probably a Java-style string-builder class,   
   where you assemble stuff and at the end verify if it worked. Of course   
   that means no more code like read_file(path / (title + ".txt")).   
   4. return values   
   You can't return anything from a function that might fail, because you   
   need the return slot for the error code. That means you can't store the   
   result in a constant, which checks/documents the value isn't modified   
   further, i.e. a functional programming style. Alternatively, you could   
   always pass in a reference to the error code in order to free up the   
   return slot. Validation of the errorcode would at least require a second   
   line after the call, returning in case of errors a third. Apart from   
   having to write it for every call of a function, you also have to read   
   it each time a function is called. This routes significant amounts of   
   brainpower away from solving the real problems.   
      
      
   Uli   
      
      
   --   
         [ 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)