httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <>
Subject Re: logging APR errors
Date Mon, 17 Jul 2000 20:43:08 GMT
At 12:54 PM 07/17/2000 -0700, wrote:
>Take a closer look.  I didn't even have to really search the code.  At
>times, Apache logs errors for ap_stat, at other times it doesn't.  I would
>bet there are more functions like that.

The ap_stat function is a bad example.  It doesn't need extended error 

>So, what you are advocating, is magically logging the error in some cases, 
>and making the application log the error in other cases.  This is 
>ugly.  This will look like:
>ap_log_error(.... "Stat failed");
>This doesn't seem like an awful hack to you?  You are logging some errors
>in your app, and some errors are just magically logged to the log file.

This doesn't seem like any more of an awful hack than sometimes logging 
that ap_stat failed, and sometimes not.  In either case, it requires that 
the author know something about the error handling semantics of the 
function being called.

>How we log is based on where we are in the code, and what information we 
>have access to.[...]If we pass the same pool with the same user_data to 
>two different APR functions, we will always log using the same error 
>function (ap_log_error/ap_log_rerror).

There might be some issues here, but I'm not sure.  What would determine 
whether ap_log_error or ap_log_rerror would be used?  Is it the type of 
failure that occurred?  If so, why can't the reporting function make the 

I looked at this function, and it doesn't appear that any of the ap_log_ 
functions are being called because of APR failures.  Do you have a better 
example?  I assume that there must be some case where this happens, and I'd 
really like to take a look at it.

> > > The design I am leaning most towards right now, is for APR to define a
> > > bunch more error values, and just return them in the correct spots.
> >
> > I'll look forward to seeing it.
>The code is there, and the design is done.  Add a couple of more error 
>values, and return them where appropriate.  This lets the App deal with 
>errors, which is the correct solution.

Both solutions let the app deal with errors.  They merely differ in how the 
app deals with the errors, so saying that this is the correct solution 
because it lets the app handle the errors is nonsense.  Does this design 
still just return error codes, or has some additional information been added?

View raw message