httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject error handling suggestion
Date Tue, 18 Jul 2000 08:25:24 GMT
Rather than use a callback for logging errors, why don't we just return the
data to the caller and let the caller decide?

Ryan's point about context is quite valid. It gets rather difficult to prep
the callback context for each of the calls into APR. But the *caller* of an
APR function knows the context. If not, then it just returns the data
further up until somebody does know.

When the caller gets an error, it can log the problem, or it can punt it up
to the next level.

I'll write a short design proposal here:

*) introduce an error structure:

   struct ap_error {
       ap_status_t status;
       const char * msg;
       struct ap_error * next;
   }

*) ->status contains the function result status. same as we return today.

*) ->msg contains descriptive text for the message

*) ->next is used to chain errors from low-level to high-level messages. For
   example, ap_write() returns { APR_ENOSPC, "out of space", NULL } (call it
   "error"). The caller creates a new error structure with { APR_ENOSPC,
   "could not PUT the resource.", error }. etc.
   
   The outermost ap_error_t contains a nice high-level description.
   Following the ->next pointer, we can find the low-level cause of the
   problem.

*) note that errors must be dynamically allocated. most APR functions have a
   pool that can be used. ->msg can typically be a const string, but if it
   must be constructed, then it would also use the pool.

*) there is a concern that a loop that generates/discards errors create an
   unbounded amount of memory. we could introduce an "error pool" in APR.
   this could be set on a per-thread (request) basis. if the app knows that
   it will be discarding errors within a loop, it could call ap_clear_pool()
   on the error pool to reset it.

*) msg could be left NULL, indicating that ap_strerror() should be used to
   get the message.

*) ap_error could have an "id" field added that allows for specification of
   where an error was generated. essentially a sub-status, but without the
   problems of overlapping ranges in ap_status_t values


Anyways... food for thought. I've used a structure similar to above in
mod_dav with great success. When the top-level gets an error, it just
iterates down the links dropping the items to the log. It is pretty cool
because you get a list from high-level down to low-level about the error.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message