Neels Janosch Hofmeyr wrote on Mon, 9 Jun 2008 at 02:02 +0200:
> Daniel Shahaf wrote:
> > Neels Janosch Hofmeyr wrote on Thu, 5 Jun 2008 at 03:25 +0200:
> >> Daniel Shahaf wrote:
> >>> Hmm, that docstring (and validate_prop()'s docstring) also promise that
> >>> you'll return SVN_ERR_BAD_PROPERTY_VALUE. So you need to wrap your
> >>> errors by that error.
> >> That's right, so it would suffice to just throw a
> >> SVN_ERR_BAD_PROPERTY_VALUE for both cases of inalid UTF-8 and
> >> inconsistent EOL style, and I don't need a SVN_ERR_INVALID_UTF_8 even if
> >> it was there already. (The function validate_prop directly correlates
> >> with the mentioned comment, so it wouldn't make sense to throw
> >> differentiated errors only to wrap them to a more general error within
> >> the same function.)
> >>
> >
> > Why do you think that it "wouldn't make sense"? Do you think this
> > information is useless to callers of these APIs?
>
> The point is that validate_prop() is currently a private function in
> subversion/libsvn_repos/fs-wrap.c, and that it is only ever used in
> cases where the specification is to return only
> SVN_ERR_BAD_PROPERTY_VALUE. To return more precise errors would mean
> that the callers in fs-wrap.c would *all* wrap code around the
> validate_prop() call that abstracts every error to
> SVN_ERR_BAD_PROPERTY_VALUE.
I assumed it would just be
if (log message is not valid UTF-8)
return svn_error_create(SVN_ERR_BAD_PROPERTY_VALUE,
svn_error_create(SVN_ERR_EOL_BIKESHED),
NULL);
locally in validate_prop(). However,
> It would make more sense (I tried to say) to just make validate_prop()
> return SVN_ERR_BAD_PROPERTY_VALUE, until someone actually needs more
> differentiated error codes.
>
+1 here. Let's move on.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-09 09:08:41 CEST