You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2002/08/15 20:28:17 UTC
Re: svn commit: rev 2977 - trunk/subversion/include
kfogel@tigris.org writes:
> +#define SVN_ERR_APMOD_CATEGORY_START (APR_OS_START_USEERR \
> + + (14 * SVN_ERR_CATEGORY_SIZE))
> +#define SVN_ERR_CLIENT_CATEGORY_START (APR_OS_START_USEERR \
> + + (15 * SVN_ERR_CATEGORY_SIZE))
> +#define SVN_ERR_MISC_CATEGORY_START (APR_OS_START_USEERR \
> + + (16 * SVN_ERR_CATEGORY_SIZE))
> +#define SVN_ERR_CL_CATEGORY_START (APR_OS_START_USEERR \
> + + (17 * SVN_ERR_CATEGORY_SIZE))
>
> SVN_ERROR_START
Do we need to support applications that want to use APR_OS_START_USEERR
without conflicting with Subversion? We could reserve some spare
categories after 17 and provide a name for the first application error
number.
#define SVN_ERR_START_USEERR (APR_OS_START_USEERR+30*SVN_ERR_CATEGORY_SIZE)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 15, 2002 at 05:22:47PM -0500, Karl Fogel wrote:
>...
> Let's make a special start place for them:
>
> SVN_ERR_USERERR_START
>
> or something, like APR does. Our command-line client errors can just
> move into this space.
Nah. If a library uses that, and an app uses the range and the library, then
you'll have conflicts again.
There is no answer, short of altering APR's error mechanism. The short
answer is that "apr_status_t" would need to include an "authority" component
that specifies who is defining the particular error ID.
>...
> Before we do this, though, I'd like for Greg Stein's plane to land so
> he has a chance to see this discussion :-). Just an instinct that if
> there are any gotchas to be noticed here, he'll notice them.
It's really an insoluable problem, so I would not suggest that we bother
with it. I'd much rather see us punt than to pretend that we have a solution
which isn't going to work anyways.
Consider me -0.5 on the proposal. If you *do* go ahead with it, then please
summarize my issues in the comments about the symbol. (thx)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> More or less. I don't think it matters whether SVN_CL_* is part of
> the Subversion "internal" range or part of the Subversion
> "application" range. Those errors are always likely to be defined in
> the main subversion include files, and not in an application specific
> file, as they use the SVN_ERRDEF macro.
>
> If, rather than defining a new name, we decide that other applications
> should use SVN_ERR_CL_CATEGORY_START then we should put a few spare
> categories between it and the preceding category.
Let's make a special start place for them:
SVN_ERR_USERERR_START
or something, like APR does. Our command-line client errors can just
move into this space.
This category will have as much room as any other Subversion error
category, initially, but we'll keep it positioned last in the
categories, in case we ever need to reserve the next category range to
double it (etc, etc).
Before we do this, though, I'd like for Greg Stein's plane to land so
he has a chance to see this discussion :-). Just an instinct that if
there are any gotchas to be noticed here, he'll notice them.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Or maybe: our client should be just one of many users of this special
> reserved range. That is, we should make the SVN_CL_* error range be
> available in general for users of the Subversion libraries. Our
> command-line client will make its own use of that range, but of
> course, any other Subversion client -- say, a GUI client -- could also
> return errors in that range, because none of our libraries would ever
> do so (or shouldn't, anyway).
>
> How does that sound? (Or is that basically what you were proposing?)
More or less. I don't think it matters whether SVN_CL_* is part of
the Subversion "internal" range or part of the Subversion
"application" range. Those errors are always likely to be defined in
the main subversion include files, and not in an application specific
file, as they use the SVN_ERRDEF macro.
If, rather than defining a new name, we decide that other applications
should use SVN_ERR_CL_CATEGORY_START then we should put a few spare
categories between it and the preceding category.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Now how does the application define APP_LOGIC_ERROR1? At present the
> only way to avoid clashes is to translate all Subversion errors into
> application errors and never propogate the subversion ones.
>
> Our client, svn, gets its own category. I'm suggesting something
> similar for other applications.
Or maybe: our client should be just one of many users of this special
reserved range. That is, we should make the SVN_CL_* error range be
available in general for users of the Subversion libraries. Our
command-line client will make its own use of that range, but of
course, any other Subversion client -- say, a GUI client -- could also
return errors in that range, because none of our libraries would ever
do so (or shouldn't, anyway).
How does that sound? (Or is that basically what you were proposing?)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
> > Do we need to support applications that want to use APR_OS_START_USEERR
> > without conflicting with Subversion? We could reserve some spare
> > categories after 17 and provide a name for the first application error
> > number.
>
> How would such a conflict happen?
>
> There's no problem if two libraries want to use the same numbers in
> their error codes. Callers know which library's functions they're
> calling, so they will be checking error codes "in the right context",
> so to speak.
I suppose interpretation "in the right context" is the only solution
that will work if libraries other than subversion are being used.
However if the application uses only Subversion, it may want to use
apr_status_t to report it's own errors within the application code.
apr_status_t app_function()
{
if (...)
/* Yikes! An application error */
return APP_LOGIC_ERROR1;
svn_error_t* err = svn_client_xxx();
if (err)
return err->apr_err;
}
int main()
{
apr_status_t app_err = app_function();
if (app_err)
/* Handle error */
}
Now how does the application define APP_LOGIC_ERROR1? At present the
only way to avoid clashes is to translate all Subversion errors into
application errors and never propogate the subversion ones.
Our client, svn, gets its own category. I'm suggesting something
similar for other applications.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2977 - trunk/subversion/include
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Do we need to support applications that want to use APR_OS_START_USEERR
> without conflicting with Subversion? We could reserve some spare
> categories after 17 and provide a name for the first application error
> number.
How would such a conflict happen?
There's no problem if two libraries want to use the same numbers in
their error codes. Callers know which library's functions they're
calling, so they will be checking error codes "in the right context",
so to speak.
Maybe I'm misunderstanding your proposal?...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org