Re: Generic errors

[Joe Orton <jo...@redhat.com>]

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

Re: Generic errors

[Graham Leggett <mi...@sharp.fm>]

On Wed, April 11, 2007 12:15 pm, Joe Orton wrote:

> What problem is this supposed to solve?

The problem is that APR doesn't yet have a standardised way to provide
"rich" error messages back to the end user. LDAP does one thing, SQL does
another. Yuck.

The simplisitic "one error string per error code" doesn't provide anywhere
near enough resolution to practically support the toolkits we use.

> 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.

Exactly, thus the problem.

Remember also that not all toolkit errors are generated by the underlying
toolkit - sometimes errors are APR generated. The end application should
not have to care how the error happened, only how to the the message.

> 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".

To be thread safe what could be possible is to attach the error to the
pool being used somehow.

Of course we need to resolve the case where pools are cleared before the
function returns, but it is reasonable however to expect people to use the
pools if they want to use the errors.

Regards,
Graham
--