apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: Generic errors
Date Wed, 11 Apr 2007 10:55:41 GMT
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.


View raw message