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: Generic errors
Date Thu, 29 Mar 2007 11:51:52 GMT
Nick Kew wrote:
> On Thu, 29 Mar 2007 10:11:52 +0100
> David Reid <david@jetnet.co.uk> wrote:
> 
>> I'd like to take Grahams idea for ldap and move it into "core" apr.
>> The idea would be morphed slightly to work as shown below.
>>
>> We add a new structure, apr_err_generic_t which is used to contain
>> details of an error that can't be described by a single code. The
>> intent is that it's used when an underlying "subsystem" that apr
>> relies on generates an error - ie the ldap daemon reports a problem
>> or mysql can't process a query.
> 
> +1 in principle to an overhaul of error handling.  Can't comment
> on LDAP specifics because I haven't studied them.
> 
> FWIW, apr_dbd takes a half-hearted stab at this problem, but not
> one that I'd propose as a model for generalising.
> 
>> When this happens the function return APR_EGENERIC which means that
>> the user knows a problem happens, that it was related to a subsystem
>> and that there is more information available. They would then call
>> another function to get the error structure. This could then be used
>> to generate an error string via apr.
> 
> If the error structure itself is opaque and internal to apr_ldap,
> and there's some sane (simple and generic) API for addressing it,
> then by all means abstract that to an apr_error module.
> 
Graham pointed out that ldap uses it and it's very small and could be
easily adapted to a more generic solution. The code is easily found in
the ldap files (it must be - it took me about 30 seconds).

Mime
View raw message