> From: Aaron Bannert [mailto:[EMAIL PROTECTED] > > 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
