[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_stream_copy3() in svn_io.h

From: Greg Hudson <ghudson_at_mit.edu>
Date: Wed, 08 Apr 2009 10:49:41 -0400

On Wed, 2009-04-08 at 06:20 +0200, Greg Stein wrote:
> Proper use of goto can greatly simplify a function. Bending over
> backwards to create if/else sequences or flags or whatever... just in
> order to note "cleanup" status ... can be much more complicated than a
> simple goto.

Agreed. Basically, if you only "goto" to a single label at the end of a
function, you are just mirroring the pattern of a try-finally block in a
language which has such functionality, and it's fine. Duplicating
resource cleanup code every time you see a failure is a much worse
alternative.

There *is* an alternative which avoids duplicate resources freeing and
doesn't use goto. It's called "if ladders" and looks like this:

  do stuff that can't fail;
  err = something_that_can_fail(...);
  if (!err) {
    do stuff that can't fail;
    do more stuff that can't fail;
    err = something_that_can_fail(...);
  }
  if (!err) {
    more stuff that can't fail;
    err = something_that_can_fail(...);
  }
  clean up resources;
  return err;

However, some people find it difficult to read at first, because the
main logic of the function gets shunted to the right one level at the
first failure point. Also, inside a loop with more than one failure
point, the logic again gets shunted another level to the right, so your
loops effectively use double the indentation real estate.

Subversion has mostly avoided this problem because pools save it from
having to do explicit resource cleanup in most circumstances. Actually,
don't we normally deal with this kind of thing using pool cleanup
handlers?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1597650
Received on 2009-04-08 16:50:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.