Re: Software landmines (loops)

["Mattias Lundstr�m" <ehsmalu@ehpt.com>]

Aggresive cuttings below.

Robert Martin wrote:
> 
[...]
> This is roughly equivalent to the 'finally' solution in another post.  And
> I'll use the same argument.
[...]
[Loop that sets return value 'retval' and does 'goto error_exit' on
error]
> error_exit:
>   if (p) free(p);
>   if (f) fclose(f);
return retval;
// The point is that this is code that is ALWAYS executed.
// The only "multi-exit" issue here is the multiple exit
// points from the loop. The function has only this exit.

Your problem with this is (as I understand you) is the use of flags 
(or other method of tracking) to be able to say 

if( resource1 allocated ) deallocate( resource1 );
if( resource2 allocated ) deallocate( resource2 );
...
if( resourceN allocated ) deallocate( resourceN );

How do you mean that you could avoid this by a single-exit
solution ?

> 
> The redundant resource cleanup, and the checks made in the error_exit
> section are pretty ugly.  And this ugliness will only grow and become more

Perhaps. But I do think they are unavoidable. You may break them up
over multiple functions when and if they become too complex, but this
has really nothing to do with the single/multi-exit issue.

> contorted over time.  Also, it is not guaranteed that all resources will
> have check functions, forcing the use of flags (which is all p and f are
> used for in error_exit) in order to determine when it is safe to release
> such a resource.
> 
> Single-entry/single-exit (se/se) structures always have appropriate places
> for acuiring and freeing resources.  The state of the algorithm is encoded
> into the structure.  Multiple exits, gotos, finally clauses, destructures,
> etc, all *lose* state information.  Once they are invoked, the previous
> state of the algorithm can only be recaptured by investigating the data and
> within the algorithm.  This means flags that cover the entire scope of the
> algorithm must be maintained so that the error recovery code can determine
> what to do.

The whole point of having resource deallocation at the end of the
loop is that you do not want to distribute this into many places.
Are you (I hope not) proposing something like

while( loop should continue )
{
  ...
  if( error 1 )
  {
    do some deallocation
    set flag(s) not to continue
  }
  ...
  if( error 2 )
  {
    do some oother (possibly overlapping) deallocation
    set flag(s) not to continue
  }
...
}

> The decision to use multiple exists (other than exceptions) is a short term
> decision that will probably yeild short term benefits.  But in the long term
> the decision has the potential to cause significant pain.  Personally, I
> have experienced enough of that sort of pain, so I am pretty careful about
> se/se.

As can be deduced from the above I do not agree with you ;-)

Btw. Why, in your opinion, are exceptions different?

- Mattias