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

Re: svn commit: r19108 - trunk/subversion/libsvn_ra_serf

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-03-31 21:48:42 CEST

On Fri, 31 Mar 2006, Garrett Rooney wrote:

> On 3/31/06, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > On 3/31/06, Daniel Rall <dlr@collab.net> wrote:
> > > I prefer Greg's suggested form on the grounds that it seems more
> > > consistent with error handling in the rest of Subversion's source.
> >
> > It's a variable not a function. That's why it seems, well, wrong.
>
> I've seen that idiom (wrapping a variable in SVN_ERR) used in other
> places in the svn code. It's not overly common though.

Based on the macro's doc string, I can see where Justin's reaction was
coming from.

However, there's really little reason to avoid use of SVN_ERR(expr)
when expr is not a function call. How about something like this?:

[[[
* src/subversion/subversion/include/svn_error.h
  (SVN_ERR): Tweak macro doc string to avoid making it seem that it
   should only be used when evaluating return value of a function,
   since it can also be used when evaluating variable.s
]]]

Index: src/subversion/subversion/include/svn_error.h
===================================================================
--- src/subversion/subversion/include/svn_error.h (revision 19113)
+++ src/subversion/subversion/include/svn_error.h (working copy)
@@ -205,7 +205,7 @@
 void svn_handle_warning(FILE *stream, svn_error_t *error);

-/** A statement macro for checking error return values.
+/** A statement macro for checking error values.
  *
  * Evaluate @a expr. If it yields an error, return that error from the
  * current function. Otherwise, continue.

  • application/pgp-signature attachment: stored
Received on Fri Mar 31 21:49:33 2006

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.