apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: additional error code
Date Wed, 21 Jun 2006 21:12:28 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 

Agreed. I plan on trying to do this, but also agree with Graham that
there must be a way to get the *raw* error code from the library.
Whether that will be useful isn't something a library should decide :-)

In the same vein, maybe have a function to return the "type" of library
being used? apr_ssl_library_name() or some such?

> 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)

A good idea. I'll look at adding some error codes to apr-util later.


View raw message