I really like the way the RDB and VMS log error messages.
They are categorized with:
%<APP>-E-
%<APP>-W-
%<APP>-I-
For Error, Warning, and Informational level messages.

For example:
%DCL-I-SUPERSEDE, previous value of CNXSERVICE has been superseded
(DCL reports that an environmental variable has replaced an older value)

%RDB-W-META_WARN, metadata successfully updated with the reported
warning -RDMS-W-PRFCREATED, some users or roles were created
(A 'grant all' on table <table> to <user> causes RDB to warn that
users/roles were created)

%RDB-E-STREAM_EOF, attempt to fetch past end of record stream
(Cursor fetch on end of stream [one error that really isn't much of an
error])

It is especially nice when you are searching through a detailed log
file.  You can look for all warnings/errors by searching for a percent
sign.  You can search for error level messages by searching for a "-E-"
and that sort of thing.

Wed, 14 May 2003 14:13:52 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Error message style guide, take 2
Dann Corbit wrote:
> I really like the way the RDB and VMS log error messages.
> They are categorized with:
> %<APP>-E-
> %<APP>-W-
> %<APP>-I-
> For Error, Warning, and Informational level messages.
> 
> For example:
> %DCL-I-SUPERSEDE, previous value of CNXSERVICE has been superseded
> (DCL reports that an environmental variable has replaced an older value)
> 
> %RDB-W-META_WARN, metadata successfully updated with the reported
> warning -RDMS-W-PRFCREATED, some users or roles were created
> (A 'grant all' on table <table> to <user> causes RDB to warn that
> users/roles were created)
> 
> %RDB-E-STREAM_EOF, attempt to fetch past end of record stream
> (Cursor fetch on end of stream [one error that really isn't much of an
> error])
> 
> It is especially nice when you are searching through a detailed log
> file.  You can look for all warnings/errors by searching for a percent
> sign.  You can search for error level messages by searching for a "-E-"
> and that sort of thing.

I'm very much in agreement here.  In addition to the advantages listed
above, this scheme is vastly superior to simply issuing error numbers
because the reader can at least get an idea of what the error itself
actually is even if he doesn't have the detail text associated with
the error.

I might be inclined (to make it slightly easier on the newbies) to
have them be of the form %<APP>-INFO-, %<APP>-WARN-, and
%<APP>-ERROR-, but that's the only improvement to the scheme I can
think of.

If it's not too late, I think we should seriously consider using that
error code scheme throughout PostgreSQL.



-- 
Kevin Brown					      kevin@sysexperts.com

Fri, 16 May 2003 14:23:04 -0700
Kevin Brown <kevin@sysexperts.com>
Re: Error message style guide, take 2
Kevin Brown <kevin@sysexperts.com> writes:
> Dann Corbit wrote:
>> I really like the way the RDB and VMS log error messages.

> I'm very much in agreement here.  In addition to the advantages listed
> above, this scheme is vastly superior to simply issuing error numbers
> because the reader can at least get an idea of what the error itself
> actually is even if he doesn't have the detail text associated with
> the error.

I didn't actually see anything to it except for a very ugly spelling of
ERROR:, NOTICE:, WARNING:, etc.  What exactly is there in their scheme
that you can't do as well or better with our existing practices?

			regards, tom lane

Fri, 16 May 2003 17:45:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Error message style guide, take 2 
Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Dann Corbit wrote:
> >> I really like the way the RDB and VMS log error messages.
> 
> > I'm very much in agreement here.  In addition to the advantages listed
> > above, this scheme is vastly superior to simply issuing error numbers
> > because the reader can at least get an idea of what the error itself
> > actually is even if he doesn't have the detail text associated with
> > the error.
> 
> I didn't actually see anything to it except for a very ugly spelling of
> ERROR:, NOTICE:, WARNING:, etc.  What exactly is there in their scheme
> that you can't do as well or better with our existing practices?

If the text of the error message is always reported to the client
library *and* the client always reports the full text of the error to
the user (and perhaps to the log), then clearly there would be no
advantage of the RDB/VMS error scheme over simply reporting error
numbers + associated error text.

But far too often, I've seen client code (not necessarily PG-related,
mind you) report an error number only without bothering to also
include the error text.  Since I was under the impression that we were
going to separate error codes from error text in the protocol, it's
possible for a client to report an error code without also reporting
the corresponding error text.  In that situation, the RDB/VMS error
scheme has significant advantages.

So it all depends on what happens on the client end, but I'd much
rather give users as much to work with as possible, even in the face
of poorly written clients.

If you think of how often you've seen programs report an error number
generated by a system call without bothering to also report the
associated error text (via strerror(), for instance), then you know
exactly what I'm talking about.

The RDB/VMS scheme gives you a great deal of readily-accessible
information in a very small package.  Error numbers don't.  So given
the choice, I'd rather go with the RDB/VMS scheme if there are no
significant drawbacks involved.

We certainly don't have to adopt that specific scheme, but I think it
would be wise to adopt an error code scheme that has the same
advantages.  For that purpose, the RDB/VMS scheme is probably at least
as good as any other.


-- 
Kevin Brown					      kevin@sysexperts.com

Fri, 16 May 2003 15:18:12 -0700
Kevin Brown <kevin@sysexperts.com>
Re: Error message style guide, take 2