apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: additional error code
Date Wed, 21 Jun 2006 15:49:22 GMT
Joe Orton wrote:
> On Tue, Jun 20, 2006 at 02:11:37PM -0700, Justin Erenkrantz wrote:
>> On 6/20/06, david reid <david@jetnet.co.uk> wrote:
>>> I'd like to commit this patch which adds an APR_ESSL error to APR. It's
>>> only use will be in the ssl code now in apr-util. Is this the right
>>> place for it?
>> Since the SSL code lives in apr-util, then I think the error code
>> definition belongs in apr-util not apr.  The way the LDAP errors work
>> is probably a halfway-decent guide.  -- justin
> 
> The key to solving this properly is to abstract away the underlying 
> error codes returned by the toolkit being wrapped - the LDAP code 
> doesn't do that, it just dumps the LDAP_* errors in a structure (and 
> hence PR 39529).
> 
> If the aim is to actually abstract away the SSL toolkit then you need to 
> work out exactly what error codes need to be returned and where (i.e. 
> have a well-defined API), then define new errors in apr-util in the 
> _USERERR space and map these from the toolkit used.  (it's a pity there 
> wasn't an error code space reserved for apr-util in apr_errno.h; that 
> would be useful to fix in APR 2.0)

Well.... nothing says the next version is 1.3 :-)  Suggestions on a richer
return value API which isn't computationally or storage intensive?

I'd agree that LDAP + SSL are both good examples to start from.  Registering
additional error spaces is a good starting point.



Mime
View raw message