On Thu, 29 Mar 2007 10:11:52 +0100 David Reid <[EMAIL PROTECTED]> 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. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
