apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: apr_dbd API ideas
Date Tue, 22 Feb 2005 11:24:05 GMT
Nick Kew said:

>> The other thing I noticed was the lack of standardized return codes from
>> the functions.
>
> Again, agreed.  I'm not quite sure what the procedure is for introducing
> new APR error codes, but ideally we should do that.

I ran into the same problem with this in APR-util and the LDAP bindings.

What I eventually did was define a return code structure that got passed
back to the caller, with the standard APR codes (I basically used
APR_SUCCESS and APR_EGENERAL).

The structure contained the raw error code of the backend (in this case
the LDAP toolkit in use), a human readable string msg representing the
error code (the LDAP API provides this), as well as a human readable
string reason with some added details of what the API was trying to do
when the error occurred.

The point behind the exercise was to prevent the calling application
having to work all of this out itself (translated as: the calling
application is very unlikely to go to the trouble to work all of this out
itself leaving the end user trying to figure out what a meaningless number
means).

The struct looks like this:

/**
 * This structure allows the C LDAP API error codes to be returned
 * along with plain text error messages that explain to us mere mortals
 * what really happened.
 */
typedef struct apr_ldap_err_t {
    const char *reason; // APR generated explanation
    const char *msg; // toolkit specific error maps to rc
    int rc;
} apr_ldap_err_t;

Regards,
Graham
--


Mime
View raw message