httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: logging APR errors
Date Fri, 21 Jul 2000 14:48:32 GMT

> > 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_stat(...)
> > ap_log_error(.... "Stat failed");
> > 
> > ap_sendfile(...)
> > return;
> > 
> > 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.
> It might seem like an awful hack if that were what I am advocating.
> For the most part, I like things how they are.  The app calls APR; if
> it fails, the app logs it.  The call-back stuff is intended only to
> handle the relatively rare cases (perhaps 10% of the APR functions?)
> where there is useful information that the caller can't derive from
> the return code.  "Which syscall failed?" is such information when the
> APR function calls a series of them.  The app would still log the
> error returned by APR; a little more info would be passed to the
> call-back prior to the return to the app.

What you are explaining will end up looking like what we have
above.  Unless, you are advocating:

ap_log_error(.... "Stat failed");

ap_log_error(... "Sendfile failed");

And the logs look like:

...Stat failed
Error in Sendfile at line 10
...Sendfile failed

This is even worse.  Now, we have log messages showing up, but the
application didn't log the information.  IMHO this is a BIG no-no.

> > 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.
> How does "Add a couple of more error values, and return them where
> appropriate" solve these problems?
> . we don't know which syscall(s) failed

difference between each macro is about 50.  In sendfile, if the first
syscall fails, return APR_ESENDFILE_SYSCALL1+errno.  And so on for the
rest of the syscalls in sendfile.  This gives just as much information,
and APR can log it all correctly using ap_strerror.

> . we need to give the app the opportunity to trace certain
>   system-specific information (e.g., name of secondary DLL on OS/2,
>   reason code on OS/390); when the extra info can be determined after
>   any syscall failure (e.g., OS/390 reason code), the app could
>   potentially do the work if it is called before subsequent syscalls
>   are made; when the extra info is specific to a certain call (e.g.,
>   name of secondary DLL), APR would have to get the info

I have two answers to this.  

1)  This isn't worth solving.  APR is meant to abstract out platform
specific information, so if we lose something for logging, then
unfortunately, that is a price we are paying for being more portable.

2)  If a given platform has a well-known log, then APR on that platform
can always just log to that location.  This should solve all problems like
this for Windows.

As far as the OS/390 reason code goes, can't that be returned the same way
we return OS/2 system errors?

> I don't doubt that you have everything worth solving solved, but it
> would be helpful to know what sort of error values you are adding and
> whether or not you will be combining it (bitwise) with the existing
> error values. 

What it all comes down to, is that the same reason we didn't take any of
these solutions two years ago still hold true.  They are inefficient, and
they impact performance on the non-error cases.  If we want to do some
bitmasking with our errors I will be all for it.  Having APR try to return
a string, or pass a string to the app just won't work for all of the
reasons outlined already.  We may lose some information, but I think that
is a reasonable price to pay.

I have looked again at NSPR, and it just uses integers to represent
errors, so I am having a hard time figuring out why we can't do the
same.  Even if it requires those integers to be bitmasked.


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

View raw message