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

Re: [PATCH] (alternate fix for issue 900)

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-09-16 16:56:02 CEST

mark benedetto king <bking@inquira.com> writes:
> > It's not exactly the same, svn_repos_open would not need to follow the
> > error chain. It could just check err->apr_err, which is how all the
> > other error checks work. Doing things differently inevitably raises
> > questions. That doesn't mean your patch is wrong :)
> >
> I guess my concern is that one of the several layers between
> apr_file_open() and svn_repos_open() might someday decide to wrap
> up the error from apr_file_open (just like svn_repos_open itself
> does, causing trouble in __split_URL).

Hey, we already have a general solution to this problem... Here I'll
describe it in the abstract:

Suppose caller Q calls function X, which depends on Y which depends on
Z. Now, Q needs to test among certain conditions that can result from
the call to X. And the conditions X returns can depend on Y, etc.

The answer is that the possible error returns need to be documented at
*every layer* in this code path, from the top caller down to the
lowest-level internal library function. Just start at the top call:
figure out what you want to test for, and test for it. Choose your
ideal interface here, since you can add newer and more specific error
returns to callees to achieve that ideal. Now document the
next-highest callee as returning those, and make sure the code does
so. If you need to go farther down and make similar changes, that's

If some of the callees are already documented to return specific
errors, and you're worried about changing their interfaces, it's
usually pretty easy to check the other callers. Anyway, 90% of the
time, you won't need to make code changes beyond the first or second
call level, you'll just need to document what the code already does.

This is what we've been doing we have such a dependency chain, and I
think ought to work in this situation too.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 16 17:19:31 2002

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.