On Tuesday 29 November 2011, William A. Rowe Jr. wrote:
> On 11/27/2011 8:34 AM, Rich Bowen wrote:
> > At Apachecon several of us were discussing how error messages
> > could be made more helpful without making them paragraphs. Two
> > suggestions were made - adding a URL to the message or adding a
> > number/code to each error that would then be looked up for more
> > information.
> > 
> > Any thoughts on 1) the wisdom of this and 2) the method of
> > assigning codes?
> 
> Keep these numeric and it will assist us in later
> internationalizing error log messages.  I was initially thinking
> in terms of using hashed strings into mapping indexes, but such
> numeric codes would be valuable.

Well, the number/code will be a number with some prefix (e.g. "AH") 
for search machine friendliness. The number could later potentially be 
used for looking up translations, but not without API changes. And I 
am not sure if that would be the smartest idea. Two log messages that 
contain exactly the same text but are emitted by different parts of 
httpd should have two distinct numbers. This may not be the best way 
to handle translations.

For 2.4, I would pass the number as part of the format string. This 
does not require any code change (in the sense of programming logic) 
and is therefore still doable in 2.4.

> 
> Ideally we could assign these numbers into the appropriate
> apr_errno range.

I think this is kind of orthogonal to having numbers in each log 
message. There is often an APR error code that supplements the log 
message. The log message says what went wrong and the error code says 
how it went wrong (e.g. message is "Can't open file %s", error code is 
ENOENT). But we don't want the error strings for APR error codes to be 
format strings. The number of the log message however could be listed 
in the documentation saying that this message happens if a client 
requests a non-existing URL.

On the other hand, we could of course make httpd APIs return httpd-
specific apr_errno values that could then be passed in the usual 
apr_status_t argument to ap_log_*error and be printed like normal APR 
error messages.


But maybe your and Mikhail's mails are showing that we should have 
some name for these error message numbers that allows to distinguish 
them from error codes as those returned by system or library calls.
Maybe "message tag" or "error tag"?

Reply via email to