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