You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2010/04/16 17:25:04 UTC
Error messages
There are a number of error messages that I find myself explaining a
dozen times a day. "That means ..."
For example, the "has no VirtualHosts" message hardly ever means that
there are no virtualhost, but rather than there's more than one
NameVirtualHost line, or that the virtual hosts don't match the
NameVirtualHost line.
So, this got me thinking, and I have two questions.
1) How long is too long for an error message? For example is something
like this too much:
Index: vhost.c
===================================================================
--- vhost.c (revision 934954)
+++ vhost.c (working copy)
@@ -507,7 +507,7 @@
if (ic->server == NULL) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, main_s,
- "NameVirtualHost %s:%u has no VirtualHosts",
+ "Either NameVirtualHost %s:%u has no
VirtualHosts, or there is more than one identical NameVirtualHost
line, or your VirtualHost declarations do not match the
NameVirtualHost line",
ic->sar->virthost, ic->sar->host_port);
*pic = ic->next;
}
2) Is there still opposition to putting URLs in error messages? What I
imagine is a series of tiny single-purpose web pages that do nothing
more than explain single error messages. So in this case, we'd have a
page that has the error message, and explains the three possible
causes of the error message, and how you'd fix each one. The error
message itself would contain a URL to that page, IN ADDITION TO the
message that's already there. That is, folks that for whatever reason
don't have net access at the moment are no worse off than they would
already have been had we not added this, so if the site goes down,
they're not completely at a loss as to what happened.
This solution has the benefit of a fully detailed explanation, but
also has the problem that the URLs would tend to be fairly long, such
as http://httpd.apache.org/docs/2.2/errors/no_vhosts.html
3) I suppose a third alternative is to log an additional message, if
we're in LogLevel Debug, that has the detailed information. Hmm. That
might be worth pursuing all by itself, even if the other two
alternatives don't pan out.
--
Rich Bowen
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Error messages
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Fri, Apr 16, 2010 at 8:40 PM, Rich Bowen <rb...@rcbowen.com> wrote:
> If that won't fly, how about instead of URLs, adding message numbers?
>>
>> E.g.
>>
>> HTTP0023: NameVirtualHost %s:%u has no VirtualHosts...
>>
>> and add a section to the doc with the explanatory web pages for
>> each message.
>>
>
> My initial response is ick, but it would make for higher Google-ability.
> I'll have to ponder on that one for a bit.
>
>
> I actually like this idea, you could event make a lookup page or so to turn
a error code into the correct redirect to the documentation.
Re: Error messages
Posted by Mark Watts <m....@eris.qinetiq.com>.
On Fri, 2010-04-16 at 14:40 -0400, Rich Bowen wrote:
> > If that won't fly, how about instead of URLs, adding message numbers?
> >
> > E.g.
> >
> > HTTP0023: NameVirtualHost %s:%u has no VirtualHosts...
> >
> > and add a section to the doc with the explanatory web pages for
> > each message.
>
> My initial response is ick, but it would make for higher Google-
> ability. I'll have to ponder on that one for a bit.
Many commercial applications do this (Oracle springs to mind) and I
think it works well for the most part.
The key trick is making sure the error code reference contains *all* of
the solutions to problems that the code applies to.
Mark.
--
Mark Watts BSc RHCE MBCS
Senior Systems Engineer, Managed Services Manpower
www.QinetiQ.com
QinetiQ - Delivering customer-focused solutions
GPG Key: http://www.linux-corner.info/mwatts.gpg
Re: Error messages
Posted by Rich Bowen <rb...@rcbowen.com>.
> If that won't fly, how about instead of URLs, adding message numbers?
>
> E.g.
>
> HTTP0023: NameVirtualHost %s:%u has no VirtualHosts...
>
> and add a section to the doc with the explanatory web pages for
> each message.
My initial response is ick, but it would make for higher Google-
ability. I'll have to ponder on that one for a bit.
>
>> 3) I suppose a third alternative is to log an additional message, if
>> we're in LogLevel Debug, that has the detailed information. Hmm. That
>> might be worth pursuing all by itself, even if the other two
>> alternatives don't pan out.
>
> Can you give an example of that?
Not sure. Was just an idea - we have a call to ap_log_error with a
loglevel of error, but then a secondary one with a loglevel of debug
so that if you're in debug you see the full verbose error message
compete with proposed solution.
I haven't actually attempted to do this yet.
--
Rich Bowen
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Error messages
Posted by Dan Poirier <po...@pobox.com>.
On 2010-04-16 at 11:25, Rich Bowen <rb...@rcbowen.com> wrote:
> 1) How long is too long for an error message? For example is something
> like this too much:
For a message that only gets logged at startup, I don't see any problem
with length. I'd be a bit more conservative if a message could get
logged on every request.
> 2) Is there still opposition to putting URLs in error messages? What I
> imagine is a series of tiny single-purpose web pages that do nothing
> more than explain single error messages. So in this case, we'd have a
> page that has the error message, and explains the three possible
> causes of the error message, and how you'd fix each one. The error
> message itself would contain a URL to that page, IN ADDITION TO the
> message that's already there. That is, folks that for whatever reason
> don't have net access at the moment are no worse off than they would
> already have been had we not added this, so if the site goes down,
> they're not completely at a loss as to what happened.
>
> This solution has the benefit of a fully detailed explanation, but
> also has the problem that the URLs would tend to be fairly long, such
> as http://httpd.apache.org/docs/2.2/errors/no_vhosts.html
I can see where those who repackage the server in commercial products
might not like having Apache URLs in all the messages. And the URLS
would be a bit long.
If that won't fly, how about instead of URLs, adding message numbers?
E.g.
HTTP0023: NameVirtualHost %s:%u has no VirtualHosts...
and add a section to the doc with the explanatory web pages for
each message.
> 3) I suppose a third alternative is to log an additional message, if
> we're in LogLevel Debug, that has the detailed information. Hmm. That
> might be worth pursuing all by itself, even if the other two
> alternatives don't pan out.
Can you give an example of that?
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org