httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: error handling suggestion
Date Tue, 18 Jul 2000 14:46:48 GMT


What you are designing here, is the exact same structure that was rejected
almost two years ago.  This was the original design for the error
structure for Apache 2.0, except it has a next pointer.  This design was
ruled out because it generates error strings even when they may not be
wanted.  It was decided that even though this only impacted the error
case, it was a big enough impact to be a bad thing.

This decision was made by the group as a whole in late 1998 or early 1999.

The other suggestion at the time was to use a rich error value
(bitmask) to describe what went wrong.  Again, it was decided that was
overkill, and we just needed a simple integer.

With those two decisions, the only option left to us, is to add error

I don't mind re-visiting the original design, but if we are going to do
that, let's at least look at the original design, because it was farily
well documented and fairly well thought out.  It was a complete design
that was made by Bill S., Ken C, Manoj and myself.


On Tue, 18 Jul 2000, Greg Stein wrote:

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

<snipped for brevity>

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

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message