apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: [PATCH]: improved error reporting for apr_dbd_mysql.c - correct version
Date Fri, 19 May 2006 12:01:24 GMT
On Fri, 2006-05-19 at 13:33 +0200, Graham Leggett wrote:

> As the code string lookups were cheap, and only done on the error case, it
> meant that a programmer was more likely to make the info available rather
> than just writing out the (useless) APR code to the end user.

I think we are confusing several different things here. For example:

APU_DECLARE(int) apr_ldap_get_option(apr_pool_t *pool,
                                     LDAP *ldap,
                                     int option,
                                     void *outvalue,
                                     apr_ldap_err_t **result_err)
    apr_ldap_err_t *result;

    result = apr_pcalloc(pool, sizeof(apr_ldap_err_t));
    *result_err = result;
    if (!result) {
        return APR_ENOMEM;

    /* get the option specified using the native LDAP function */
    result->rc = ldap_get_option(ldap, option, outvalue);

    /* handle the error case */
    if (result->rc != LDAP_SUCCESS) {
        result->msg = ldap_err2string(result-> rc);
        result->reason = apr_pstrdup(pool, "LDAP: Could not get an option");
        return APR_EGENERAL;

    return APR_SUCCESS;


The actual return codes are APR only, which is the problem we're (or at
least me :-) trying to solve in DBD. At present, random or database
specific error codes are returned throughout DBD, which make the caller
guess as to what APR type error actually happened.

In the above LDAP code, there are three separate APR conditions:


So, the user already knows (roughly) what went wrong. If something more
specific is required, it can be obtained from result->msg/reason, which
is cool. This is what DBD offers now with apr_dbd_error() and through
native handles, by getting native error codes. However, we don't have
the first error handling sorted out yet - the APR error code based one.

As a separate but related issue, I also believe that we should be a
little bit more specific with APU DBD codes anyway (e.g. by mapping some
of the natives to existing APR errors consistently or even inventing a
few new ones). There is no need to dive into native errors unless
absolutely required. They will vary wildly between back-ends which kind
of makes programming to DBD pointless in majority of cases (i.e. once
we're doing native stuff, we may as well go all native and forget DBD


View raw message