From: francis.glassborow@btinternet.com   
      
   On 07/11/2011 09:10, Dave Abrahams wrote:   
   > on Sun Nov 06 2011, "A. McKenney"  wrote:   
   >   
   >> Francis Glassborow wrote:   
   >>   
   >>> ... Too many mediocre programmers do not realise that exceptions   
   >>> are not just another way to handle error situations but deliver useful   
   >>> resource handling....   
   >>   
   >>      I confess, this statement baffles me.  What sort of "useful   
   >>      resource handling" do exceptions provide in non-error situations?   
   >   
   > I was going to ask the same thing.   
      
   I was intending to allude to the fact that exception allow automated   
   release of resource via dtors even when an error condition arises. Sorry   
   for the obfuscation.   
      
   >   
   >>> ... 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.  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.   
   >   
   > Exceptions nudge the programmer—if she hasn't already made this step in   
   > her thinking for other reasons—toward adopting a more powerful way of   
   > thinking about her code.  This way of thinking emphasizes things you can   
   > understand statically—like preconditions, postconditions, and   
   > invariants—and de-emphasizes things that require analyzing dynamics,   
   > like control flow.  Concurrency pretty much forces the same kind of   
   > mental shift.   
   >   
   > Once you've made that shift and you understand how to couple conditions   
   > to a scope with RAII, everything gets easier to think about, including   
   > resource management in code that uses error codes instead of exceptions.   
   > And in that mental context, correct resource management with exceptions   
   > is generally easier than correct resource management with error codes   
   > and explicit control flow.   
   >   
   >   
   >>     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.   
   >   
   > True, there's definitely no single right answer for every situation.   
      
   Indeed, exceptions add another tool for handling 'errors'. It is not the   
   be all and end all solution. Error codes are fine if the error can be   
   handled locally (i.e. in the calling function) Where error codes get   
   cumbersome is when the point of handling is likely to be remote from the   
   point of detection. Effectively every intermediate function has to   
   detect the error and relay it. You also have to release resources as you   
   unroll the stack.   
      
   C uses setjmp and longjmp but that inevitably leaks resources.   
      
   Of course there are skilled programmers who make considered decisions   
   about how to handle an 'error' condition. However in my experience most   
   of those who decry the use of exceptions do so for bogus reasons (such   
   as avoiding having to write exception proof code). What they ignore is   
   that when an 'error' occurs something has to be done even if it is   
   choosing to ignore.   
      
   Actually the majority of exceptions deal with exceptional circumstances   
   and those are not errors. It isn't an error to find a file is missing,   
   but it is a problem that needs to be addressed. It maybe that the   
   problem can be dealt with locally (a missing file is often such a   
   problem) but it can be something that requires backtracking some way.   
      
   Note that many real errors require program closure, the only question is   
   what is the safest and most gracious way to close.   
      
      
   --   
         [ 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)