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

Re: svn commit: r26483 - in trunk/subversion: include/private libsvn_fs_util libsvn_wc

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-09-09 01:33:11 CEST

On 9/6/07, dlr@tigris.org <dlr@tigris.org> wrote:
> Author: dlr
> Date: Thu Sep 6 10:09:35 2007
> New Revision: 26483
>
> Log:
> Formalize a flow control macro which we apparently use in several
> places already.
>
> * subversion/include/private/svn_flowcontrol.h
> New header file, providing a MAYBE_GOTO() macro.

I'm not really sure how compelling this is: I don't think that

  MAYBE_GOTO(cleanup, err);

is actually any clearer than

  if (err) goto cleanup;

It's longer, makes the reader think a little more (since it isn't just
standard C conditional), and doesn't really hide any complexity...

On the other hand, a macro that does SVN_ERR-style error variable
allocation *would* be compelling to me (ie, a macro that saves the
developer from having to define and name yet another svn_error_t*
variable), but I'm not sure if that would work if the cleanup section
needs to be able to refer to the error. Possibly we should just be
ditching goto, factoring the "cleanup" sections into a new function,
and writing

  MAYBE_CLEANUP(something_returning_error(), cleanup_func);

which expands to

  do {
    svn_error_t *svn_error_tmp = (something_returning_error());
    if (svn_error_tmp)
       return cleanup_func(svn_error_tmp);
  } while (0);

? Except for you'd probably need some sort of context baton, so maybe not...

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 9 01:29:51 2007

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.