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