apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reid <da...@jetnet.co.uk>
Subject Re: Generic errors
Date Thu, 29 Mar 2007 17:26:19 GMT
Tollef Fog Heen wrote:
> * "William A. Rowe, Jr." 
> 
> | Does it make more sense for more complex functions to return a richer
> | result?  Or how are you thinking of associating the error with the
> | additional information in a reentrant manner?
> 
> I think I misunderstood David's proposal in the same way as you did.
> What he was thinking about was embedding either the error structure
> itself or a pointer to it in the opaque APR types, like
> apr_thread_mutex_t or apr_time_t.  So if your apr_thread_mutex_create
> call failed and returned EGENERIC you would call apr_thread_get_error
> with the apr_thread_mutex_t you passed to _create as an argument.
> 
> (David, please correct me if I'm misrepresenting your ideas here.)
> 
That's pretty close, though perhaps not the best example. It's meant
only for use on "complex" subsystems where the errors that are possible
can't be adequately conveyed by simple numeric codes.

For instance, a call to an ldap function fails - it returns APR_EGENERIC
and we call apr_ldap_get_last_error() to get a generic error structure,
which we then pass into apr_err_generic_decode() and get a string with
all the details. More complex than a simple int? Yes. Useful? Yes.

I don't see it in any way replacing the codes we have presently or being
used in every circumstance, but it adds an ability to report on errors
for complex systems without having to add thousands of single use case
error values...

Mime
View raw message