On Thu, Mar 29, 2007 at 10:11:52AM +0100, David Reid 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.
What problem is this supposed to solve? The problem with the SSL code is a lack of abstraction; it's not possible to differentiate SSL errors without using the API of the underlying SSL toolkit. The same is true of the LDAP error handling: it puts the LDAP_* error code in a structure and let the app interpret it directly. If all you want to do is return human-readable error *strings* then none of this is necessary anyway; just have a function which returns the appropriate error string for the last SSL error, and a single apr_status_t error which indicates "SSL toolkit error". joe
