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 21:23:56 GMT
At 01:59 PM 07/17/2000 -0700, wrote:
>On Mon, 17 Jul 2000, Greg Marr wrote:
> > 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
> > handling.
>It is an example of logging not always being needed.  Yes, I could search 
>the code and find an example of an APR function that requires extended 
>logging sometime being logged, and sometimes not.  I don't have the time 
>nor inclination to do so.

How can you use it as a reason why the scheme doesn't work when you can't 
back up your reason.

> > >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.
>Sometimes it doesn't make sense to log ap_stat.  We use ap_stat to look 
>for .htaccess files.  If they aren't there, ap_stat fails, but we don't 
>want to log that information.  Other times, it's a real problem that 
>ap_stat has failed.

That's my point exactly, thank you.  Sometimes when an APR call fails, the 
error needs to be logged by the app that called the function, and sometimes 
it doesn't.  That doesn't seem like an awful hack to me.

> > >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
> > determination?
>Because the logging function doesn't know where we are in the code.  It 
>isn't the type of error, it's where in the processing of a request the 
>error occured.  It is based on the state of Apache, not the error itself.

You haven't shown an example where this is the case.

>Yes, which function to call can be passed down, but that requires 
>inserting that information before each call to APR function.  This is 
>overhead in the main-line case.  Get rid of that overhead in the main-line 
>(no error) case, and I will no longer consider this a hack.

The overhead hasn't been shown to exist yet.  If you can show that there is 
a case where this overhead can exist, and no one can show a method that 
eliminates this overhead, then I might agree with you.

> > >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?
>Making APR call back into the app to log an error is not the same as just 
>letting the app receive the error and just log it.  I'm sorry, it just 
>isn't the same thing.

I didn't say it was.  I said they were both the app dealing with 
errors.  If you want to say "It lets the app deal with errors by examining 
the result code returned by the APR function and logging based on that 
result code, which is the correct solution." then that would be more 

Thus far, I disagree that your statement is correct, because I haven't seen 
an example where the other method doesn't work, and just throwing more int 
values at the problem doesn't seem like the right solution.

I just had another thought.  Someone recently mentioned something about 
returning a list of errors from a function.  Is there ever a possibility of 
multiple "errors" in the same function?  That is, can an APR function run 
into an error from a system function, but still be able to continues on 
with the execution of the function, perhaps through another system 
call?  If so, how would the integer error code deal with something like 
that?  Is that something that the application would care about?  It would 
be very straight-forward for the callback scheme to log that non-fatal error.

View raw message