> From: Aaron Bannert [mailto:aaron@clove.org]
>
> On Tue, Jul 02, 2002 at 04:53:28PM -0400, Cliff Woolley wrote:
> > My suggestion was going to be to just add a parameter that is an
int*
> and
> > return true/false that way. If false is returned, you can check the
> > apr_status_t to see what happened. Or maybe it should be the other
way
> > around, with int returned and an apr_status_t* in the parameter
list.
>
> I was considering that as well, and at this point I think that is a
> better general solution. Non-APR functions that want to use APR's
> apr_status_t codes don't have the luxury of being able to add another
> code, so given the performance tradeoff maybe this is the way to go...
No. Passing in an int * to get a Boolean back is completely insane. We
spent months coming up with an extensible error reporting framework that
could be extended by applications using APR. There are status ranges
that are usable by external apps.
This is really simple to solve, and it was how APR was designed. Return
a proper status code from the function. APR_EGENERAL has two problems
in this case. 1) The APR_E signifies that this is an error condition,
which it isn't. 2) APR_EGENERAL doesn't really mean anything and
should never have been added to the code. There is no such thing as a
general error, either there is a problem, and the user needs to know
what happened, or there isn't. A general error means that something bad
happened, but the user doesn't need to know what it was.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 2 23:15:48 2002